emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: vc-cvs-parse-entry


From: Eli Zaretskii
Subject: Re: vc-cvs-parse-entry
Date: Fri, 15 Sep 2006 20:43:43 +0300

> Date: Thu, 14 Sep 2006 10:40:04 +0200
> From: martin rudalics <address@hidden>
> CC:  address@hidden
> 
>  > I wasn't talking about DST, I was talking about the time-zone offset
>  > from UTC.  Most time zones have non-zero offset between UTC and the
>  > local time even when the DST is not in effect.
> 
> Yes, but my problem isn't with time-zones.  It's with DST just as
> described there.

Understood and agreed.  However, this confusion started when you
claimed that FindFirstFile did not return UTC times, but local times.
I hope now we agree that it does return UTC times, except that those
times are sometimes off by one hour due to the incorrect DST
correction.

>  > I was talking about what FindFirstFile returns, not about what's
>  > recorded on disk.  There's no argument that NTFS records file times in
>  > UTC, while FAT records them in local time.  The question is: does
>  > FindFirstFile convert file times to UTC on FAT volumes; the MS docs
>  > tells quite clearly that it does.  Can you please verify that
>  > directly, and show the actual numbers returned by FindFirstFile on
>  > your system?
> 
> You earlier said that `stat' runs FindFirstFile.  Without options stat
> (version 5.3.0) gives for my standard time-zone settings (CEST):

I meant the _function_ `stat' as implemented in Emacs's w32.c.  I did
not mean the _program_ `stat' that is part of Coreutils.

If you can step with a debugger through the function `stat' in w32.c
and see what times it returns for your files, it'd be great.

> Can you tell something from that?

Not really.  It's quite obvious that `stat' the program converts the
times to local time for display (witness the +0200 etc. time-zone
offsets it shows).  I need to see the raw times returned by the
FindFirstFile API.

Anyway, I'm not sure anymore whether we should pursue this issue any
further, especially since Stefan thinks we shouldn't try fixing this.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]