Barry Pederson wrote:
> 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:
> 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())
We use APR for that, and APR is (should be) consistent across platforms,
so that's not an issue. (Specifically, on Windows, it uses the Win32 APIs.)
And yes, whatever timestamps we store in .svn/entries or send over the
wire should be UTC; svn_time_to_nts and svn_time_from_nts are the places
where this should be fixed.
Parsing timsetamps from the -D option, and what goes into "svn log" and
"svn info", is a different matter. There used to be a patch floating
around that implements apr_strptime (an strptime replacement) for the
parser -- I think I still have it lying around. I think Mark Benedetto
King (email@example.com, firstname.lastname@example.org) is/was working on that, too.
For everything else, we should be using apr_strftime to format the
output. Whether the format should be locale-specific, ISO-8601, or
perhaps even configurable via the config file, is something we have do
discuss and decide. I suppose a user-friendly version of ISO-8601 (space
instead of the T separator, etc.) would be a reasonable default.
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon May 6 21:41:41 2002