bug-cvs
[Top][All Lists]
Advanced

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

Re: FW: CVS algorithm for update


From: Derek R. Price
Subject: Re: FW: CVS algorithm for update
Date: Wed, 14 Mar 2001 15:08:27 -0500

Atempting to move this discussion to bug-cvs....

Jeff,

I don't remember all the details except that I tested the Windows behavior
fairly extensively and plowed through quite a bit of documentation.  My
testing was done under NT using an NTFS file system, and my conclusions are
similar to the ones you describe.  Namely, stat is defined by POSIX as
returning the time in UTC but the windows version always returned the UTC
time offset by 3600 when daylight savings time was in effect.

I checked in the kludge since I didn't expect MS to respond quickly to my
bug report.  I'm not actually sure I got far enough past the paid support
pages to figure out where I could file a report.  I may have abandoned the
effort in the hopes that some paying customer would report the problem
eventually.

Are you suggesting that the same thing doesn't happen under Win9X and NT
using FAT32 filesystems?

Derek

--
Derek Price                      CVS Solutions Architect ( http://CVSHome.org )
mailto:address@hidden     OpenAvenue ( http://OpenAvenue.com )
--
I will not fake seizures.
I will not fake seizures.
I will not fake seizures...

          - Bart Simpson on chalkboard, _The Simpsons_

Jeff Lawson wrote:

> Derek, here is a reply that I tried to send to the list but did not make
> it.
>
> I think unconditionally subtracting 3600 when dst is in effect is
> strictly speaking not the best thing to do to accomodate for the
> localtime correction.
>
> -----Original Message-----
> From: Jeff Lawson
> Sent: Tuesday, March 13, 2001 5:21 PM
> To: 'Larry Jones'; Stewart Brodie
> Cc: address@hidden; address@hidden
> Subject: RE: CVS algorithm for update
>
> One thing to keep in mind is that on Win32 NTFS, although file
> timestamps are stored in UTC, file timestamps retrieved and converted to
> localtime are always interpreted under the current DST offset,
> regardless of whether DST was actually in effect at the time the file
> was touched.  This well-known, documented behavior occurs in the Win32
> API FileTimeToLocalFileTime().
>
> On FAT filesystems (both under NT and Win9x), the file timestamps are
> always stored in local time at the time the file was touched.
>
> The Visual C++ 6 CRT implementation of _fstat() uses
> GetFileInformationByHandle() followed by FileTimeToLocalFileTime() and
> FileTimeToSystemTime(), without any attempt to correct for the DST
> correction anomaly that occurs in FileTimeToLocalFileTime().  It's
> doubtful that any other Win32 compiler vendors would do anything
> different.
>
> -----Original Message-----
> From: Larry Jones [mailto:address@hidden
> Sent: Tuesday, March 13, 2001 4:45 PM
> To: Stewart Brodie
> Cc: address@hidden; address@hidden
> Subject: Re: CVS algorithm for update
>
> Stewart Brodie writes:
> >
> > The datestamp comparisons seem to cause flutters when we switch
> between DST
> > and not, though - all our WinCVS users got very confused last year :-/
>
> That implies that the C library that was used when building your WinCVS
> has broken time handling code.  (This is not, unfortunately, unusual in
> the DOS/Windows world.)




reply via email to

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