Re: ISO-8601 dates and issue 614

Tim Waugh wrote:

> Unix-based systems of course use UTC, as any sane system would.
>
> The NT bug, as I recall, is that stat() will return a different
> structure before and after a DST change. The time_t fields are
> actually adjusted, and can't be interpreted as 'seconds since the
> Epoch'. (Perhaps I'm misremembering.)

That's about right, it has to do with the way date/time is stored in NTFS
partitions. Here's a Microsoft description:

   http://support.microsoft.com/default.aspx?scid=kb;en-us;Q158588

I just got burned by this a month or so ago with another program. Basically,
it seems that Windows stores GMT/UTC, and then stat() shifts the time
according to what your offset from GMT is *now* (not what the offset should
have been on the particular date associated with the time).

So it shouldn't be too difficult to compensate for that shift and get back to
GMT 'seconds since the epoch'. IIUC, for example on my machine right now (in
May), I'm at GMT+5, so if I subtract (5* 60 * 60) from the stat values, I
should get a GMT value. And come November, when DST is off, for the very same
file, subtracting (6* 60 * 60) from the stat should give the same GMT value.

The other workaround would be to not use stat(), and instead use the Win32 API
call mentioned in the link above that gets UTC directly.

Is this a problem in SVN? It looks like APR tries to take care of all that
stuff (using the Win32 API instead of stat())

        Barry

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 6 16:31:21 2002