Daylight Saving Time changes file times.

[Fred Hebert]

For years I have had problems with all of the file times
on my Windows systems changing every time Daylight Saving
Time (DST) begins or ends. I have found no way to get my
system to display the correct time, and not change the
file times.

I am a small time developer and use an automatic mechanism
for my customers to download updates across the web.
Basically the files are stored on a web server along with
a directory listing that contains file times, dates and
checksums. The client software periodically retrieve the
directory listing and use to compare to their local
files. If the file changes they download it, and verify
the download with the checksum.

This weekend everyone downloaded everything and really
swamped my server, and I am probably going to pay a
bandwidth premium. This is a real pain because no files
changed. All of the Windows clients just thought the file
times changed.

Apparently the file time is internally adjusted from the
UTC time based on the current time offset, not the time
offset that was in effect when the file was created.

Incidentally NONE of my Netware, Unix or Linux clients had
this problem.

If I turn off Automatically adjust for DST, then the file
times don't change, but the current time is always wrong.

Any suggestions on how to fix this?

 

[GwD]

Maybe you should try a different method to check for updates.

 

[Dave]

or move into the 24/7 world wide always up and running connected world where
time doesn't jump ahead or back at arbitrarily determined times so that
farmers can get extra time to exploit child labor in the fields! set your
server to utc with no dst and cast off the shackles of our agrarian past!

 

[David Candy]

Get smarter clients - they should be synching on UTC time not display time. Store your files on Fat partitions (they only use local time).

 

[David Candy]

What country do you come from? Australian farmers HATE daylight saving (something about cows go off their milk).

 

[Dave]

i'm from the states, but use utc on all my computers for ham radio... its
really a pain to convince the guys at work that they really don't want to
use automatic dst adjustments on remote data collection machines, twice a
year the data is all screwed up and they waste time and money fixing it up.

What country do you come from? Australian farmers HATE daylight saving
(something about cows go off their milk).

 

[Fred Hebert]

Actually I do not use the display tme, I use the UTC time
returned by a system call. The problem is that it returns
different results depending on wether DST is in effect or
not. After the last DST change I changed the method
hoping to avoid the problem, but no luck.

I have another plan to fix the problem, but it goes beyond
my software. My backup software did an incremental backup
monday night, but because of the file time change
everything got backed up, and the backups didn't complete
until almost noon today.

I have a mixed LAN with NT4, Win2003, Netware, Unix (SCO),
and Linux (RedHat) servers, and only the Windows servers
have the problem.

I think that a file with a time of 4:11 on Friday should
have a 4:11 time on Monday, that is displayed, UTC, or
other. Yesterday I developed a routine that looks at the
file time, and determines if it is during DST and returns
the correct time. It really shouldn't be this difficult
just to get an accurate file time.

-----Original Message-----
Get smarter clients - they should be synching on UTC time

not display time. Store your files on Fat partitions (they
only use local time).

 

[David Candy]

Well you are doing it wrong. If using UTC (aka GMT) the time doesn't change.

File Times and Daylight Saving Time
You must take care using file times if the user has set the system to automatically adjust for daylight saving time.

To convert a file time to local time, use the FileTimeToLocalFileTime function. However, FileTimeToLocalFileTime uses the current settings for the time zone and daylight saving time. Therefore, if it is daylight saving time, it will take daylight saving time into account, even if the file time you are converting is in standard time.

FAT records times on disk in local time. GetFileTime retrieves cached UTC times from FAT. When it becomes daylight saving time, the time retrieved by GetFileTime will be off an hour, because the cache has not been updated. When you restart the machine, the cached time retrieved by GetFileTime will be correct. FindFirstFile retrieves the local time from FAT and converts it to UTC using the current settings for the time zone and daylight saving time. Therefore, if it is daylight saving time, FindFirstFile will take daylight saving time into account, even if the file time you are converting is in standard time.

NTFS records times on disk in UTC. To account for daylight saving time when converting a file time to a local time, use the following functions instead of FileTimeToLocalFileTime:

1.. FileTimeToSystemTime
2.. SystemTimeToTzSpecificLocalTime
3.. SystemTimeToFileTime

 

[Colin]

Actually I do not use the display tme, I use the UTC time
returned by a system call. The problem is that it returns
different results depending on wether DST is in effect or
not. After the last DST change I changed the method
hoping to avoid the problem, but no luck.

I have another plan to fix the problem, but it goes beyond
my software. My backup software did an incremental backup
monday night, but because of the file time change
everything got backed up, and the backups didn't complete
until almost noon today.

I have a mixed LAN with NT4, Win2003, Netware, Unix (SCO),
and Linux (RedHat) servers, and only the Windows servers
have the problem.

I think that a file with a time of 4:11 on Friday should
have a 4:11 time on Monday, that is displayed, UTC, or
other. Yesterday I developed a routine that looks at the
file time, and determines if it is during DST and returns
the correct time. It really shouldn't be this difficult
just to get an accurate file time.


not display time. Store your files on Fat partitions (they
only use local time).

The reason you do not get this problem with Unix is that it is done
correctly (of course). All dates and times are stored as UTC, and only
offset when displayed. Trust MS to get it wrong.
Colin.