important caveat with Rsync on NT and dayligt savings time

[jw schultz]

On Tue, Oct 29, 2002 at 01:25:03PM -0600, wolfe-mcse at ev1.net wrote:
> Howdy...
> 
> 
> Fortunately you posted the KB article number, and having read the article, I
> see you have a bit of a misunderstanding of what is going on.
> 
> First off, NT/2000 uses a offset from GMT, which does not observe Daylight
> Savings Time (DST), for storing the time in the Event Log, and NTFS volumes.
> This also affects Windows 95, Windows 98, Windows ME, and Windows XP
> platforms viewing the same data remotely.
> 
> On the other side of file systems, the FAT16, and FAT32 filesystems use the
> number of seconds that have elapsed since January 1, 1980 to store the time,
> rather than a time offset from GMT.
> 
> In case you want to avoid this happening in the future, at least until a
> solution can be developed, implemented, and tested, you can turn off DST.
> This will mean that for one-half of the year, your clock will be out-of-sync
> by 1 hour, but it may be better to be off by 1 hour to avoid this problem in
> the future.
> 
> I appreciate you warning others about this, as it has identified a cosmetic
> bug that I was completely unaware of.  Necessity is the mother of invention,
> and this nuance will be addressed in my implementation of rsync as a service
> for Win32.

Your description is as confusing as the KB article (at least
to me).  Part of the problem with the KB article is that it
focuses on localtime displays rather than internals.

.From what i can tell FAT stores timestamps in localtime.
NTFS uses a GMT based timestamp.

I can see one of two places where we get bit.  As a matter
of curiosity i'd like to know which.

1. When the FAT timestamps are converted to GMT it is done
   based on the current TZ offset rather than the TZ offset
   in effect when the timestamp was made.

2. The NT equivalent of stat(2) is converting the NTFS
   timestamps to localtime and then the cygwin libs convert
   it back to GMT.

It would appear that the problem could be avoided either by
using NTFS or FAT filesystems.  Yes?   It certainly sounds
filesystem dependant.

I'd guess that the correct place to fix this is in the
cygwin libs.  They could be tweaked to recognize the TZ
calculation error of the NT libs.  There might need to be a
test for filesystem type (if possible) or a switch to
determine behavior otherwise what fixes some will break
others.


-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw at pegasys.ws

		Remember Cernan and Schmitt