public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Tom Tromey <tromey@adacore.com>, Bruno Haible <bruno@clisp.org>
Cc: aburgess@redhat.com, gdb-patches@sourceware.org
Subject: Re: [PATCH 9/9] gdb: use reopen_exec_file from reread_symbols
Date: Mon, 02 Oct 2023 19:19:12 +0300	[thread overview]
Message-ID: <83ttr96lq7.fsf@gnu.org> (raw)
In-Reply-To: <87ttr915sg.fsf@tromey.com> (message from Tom Tromey on Mon, 02 Oct 2023 08:02:23 -0600)

> From: Tom Tromey <tromey@adacore.com>
> Cc: Tom Tromey <tromey@adacore.com>,  aburgess@redhat.com,
>   gdb-patches@sourceware.org
> Date: Mon, 02 Oct 2023 08:02:23 -0600
> 
> >> FTR (and IIUC) the issue is that gnulib's stat yields different times on
> >> Windows hosts, because it tries to handle the timezone -- on Unix, stat
> >> reports in UTC, but on Windows it may report in local time.
> 
> Eli> Are you sure?  That's not what I know: AFAIK on Windows 'stat' reports
> Eli> times in UTC, not in local time.
> 
> I think so, see https://www.gnu.org/software/gnulib/manual/html_node/stat.html

If you mean this part:

  The st_atime, st_ctime, st_mtime fields are affected by the current
  time zone and by the DST flag of the current time zone on some
  platforms: mingw, MSVC 14 (when the environment variable TZ is set).

then I'm not sure they mean the times are reported as local times.
They just say "are affected".  My interpretation of that is that on
MinGW and MSVC times might be off by, like, 1 hour, if the DST flag at
the file's time and at current system time is different.

But I've CC'ed Bruno, who knows this stuff better, to ask him to
clarify this for us.

  reply	other threads:[~2023-10-02 16:19 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-16 10:18 [PATCH 0/9] Add executable_changed event to Python API Andrew Burgess
2023-09-16 10:18 ` [PATCH 1/9] gdb/doc: extend the description for Progspace.filename Andrew Burgess
2023-09-16 10:53   ` Eli Zaretskii
2023-09-16 10:18 ` [PATCH 2/9] gdb/python: new Progspace.symbol_file attribute Andrew Burgess
2023-09-16 10:56   ` Eli Zaretskii
2023-09-16 10:18 ` [PATCH 3/9] gdb/python: new Progspace.executable_filename attribute Andrew Burgess
2023-09-16 10:55   ` Eli Zaretskii
2023-09-16 10:18 ` [PATCH 4/9] gdb: remove one user of the executable changed observer Andrew Burgess
2023-09-16 10:18 ` [PATCH 5/9] gdb: remove final user of the executable_changed observer Andrew Burgess
2023-09-16 10:18 ` [PATCH 6/9] gdb: remove unnecessary notification of " Andrew Burgess
2023-09-16 10:18 ` [PATCH 7/9] gdb: pass more arguments to the " Andrew Burgess
2023-09-16 10:18 ` [PATCH 8/9] gdb/python: make the executable_changed event available from Python Andrew Burgess
2023-09-16 11:03   ` Eli Zaretskii
2023-09-28 14:35     ` Andrew Burgess
2023-09-16 10:18 ` [PATCH 9/9] gdb: use reopen_exec_file from reread_symbols Andrew Burgess
2023-09-19 14:08   ` Tom Tromey
2023-09-28 15:23     ` Andrew Burgess
2023-09-28 18:15       ` Tom Tromey
2023-09-29 10:17         ` Andrew Burgess
2023-09-29 15:18           ` Eli Zaretskii
2023-10-02 14:16           ` Tom Tromey
2023-09-29 14:42         ` Eli Zaretskii
2023-10-02 14:02           ` Tom Tromey
2023-10-02 16:19             ` Eli Zaretskii [this message]
2023-09-19 14:09 ` [PATCH 0/9] Add executable_changed event to Python API Tom Tromey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83ttr96lq7.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=aburgess@redhat.com \
    --cc=bruno@clisp.org \
    --cc=gdb-patches@sourceware.org \
    --cc=tromey@adacore.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).