• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 683
  • Last Modified:

Problem with daylight saving time and file modification time

One of the biggest flaws in Microsoft Windows is the fact that the modification time of files changes
when the daylight saving time becomes effective.
This happens ONLY for NTFS file systems, NOT for FAT-oriented systems.
Some of my JAVA applications check if a file has changed by comparing the modification time to a list
kept in a file.
Other JAVA applications compare the modification time of files from disk files to (e.g.) USB stick files.
As almost all USB sticks are FAT-formatted, I'm in trouble 2ce a year.

What to do?
One solution is to format all USB sticks to NTFS and keep an eye on the date.
Another solution is to keep track of file systems (FAT does not store milliseconds or even odd seconds),
but then still half of the year an offset must be added to the FAT-times.

1) how do I get the daylight saving time offset?
2) is there a better solution to this problem?
;JOOP!
0
sciuriware
Asked:
sciuriware
  • 10
  • 9
  • 3
1 Solution
 
sciuriwareAuthor Commented:
As I seem unable to format a USB stick to NTFS,
any idea how to deal with the files on FAT?

;JOOP!
0
 
CEHJCommented:
Joop, that's not really correct. The problem afaics is not with ntfs, but with client software that doesn't interpret the timestamps as UTC, which they are. IOW they only appear to have shifted when you *don't* print your dates using a UTC timezone. If you use UTC throughout, you should be fine

http://support.microsoft.com/kb/158588
0
Free Tool: SSL Checker

Scans your site and returns information about your SSL implementation and certificate. Helpful for debugging and validating your SSL configuration.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

 
objectsCommented:
We try to use GMT wherenever possible, makes life so much easier.
Not sure if possible in your case

0
 
sciuriwareAuthor Commented:
CEHJ, that 'client software' is: Windows Explorer, TotalCommander and my JAVA
applications.

As I handle the raw

               long File.lastModified()

 I don't see how to I could go wrong with timezones.

;JOOP!
0
 
CEHJCommented:
>>
As I handle the raw

               long File.lastModified()

 I don't see how to I could go wrong with timezones.
>>

You could *appear* to go wrong if you printed that date with anything other than a UTC tz set
0
 
CEHJCommented:
(Try it with and without to see the difference)
0
 
sciuriwareAuthor Commented:
You just don't get it: I DO NOT PRINT any date or time!

I compare file modification times to decide if a file must be updated
and I record only as raw longs in my list files.

;JOOP!
0
 
CEHJCommented:
>>I DO NOT PRINT any date or time!

OK - well that's different. But i bet the other two pieces of software you mentioned do:

>>that 'client software' is: Windows Explorer, TotalCommander ...

and they will probably print the date per your system time zone, which i'll bet is *not* UTC or non-DST GMT

I'll think of a test that can be done for your Java app. btw what *is* your time zone?

0
 
CEHJCommented:
(Naturally i use the word 'print' loosely, as a synonym for 'display')
0
 
sciuriwareAuthor Commented:
Any way, on UNIX I always get the UTC if I retrieve the .mtime of a file.
There is no difference between C or JAVA.

On MSWindows+NTFS I always get a "time-zoned" modification time, in C++ and in JAVA.
For some reason the raw .lastModified (JAVA) and .mtime (C++) change overnight
when DST switches on or off.
The same happens when I travel to Asia and set the time zone accordingly.
Of course I could switch off DST correction on my PC, but I don't like that.

;JOOP!
0
 
sciuriwareAuthor Commented:
>>> But i bet the other two pieces of software you mentioned do ...

Still the question is not answered: why do they both report differently for FAT and NTFS?

;JOOP!
0
 
CEHJCommented:
>>Still the question is not answered: why do they both report differently for FAT and NTFS?

"The FAT file system records times on disk in local time."

( http://msdn.microsoft.com/en-us/library/ms724290(VS.85).aspx )

Is that all clear now?
0
 
sciuriwareAuthor Commented:
Interesting article.
Well, as it seems impossible to get at the UTC timestamp of a file in JAVA I can not solve this problem in JAVA.
Right?

;JOOP!
0
 
objectsCommented:
I'm not aware of a solution, windows can be a real pain sometimes.

0
 
sciuriwareAuthor Commented:
It is!
I must format all my USB ware to NTFS to make the problem simpler, but I can't.

I'm going to repost this question in the XP area.
Thanks anyway.
0
 
CEHJCommented:
>>Well, as it seems impossible to get at the UTC timestamp of a file in JAVA I can not solve this problem in JAVA. Right?

Are you saying that Java changes the time (ntfs times *are* UTC)? (I can't experiment as i have no ntfs volume to hand)
0
 
CEHJCommented:
Joop how on earth does that 'accepted answer' answer the question?
0
 
sciuriwareAuthor Commented:
Because it enables me to solve the problem, as soon as I get rid of all those FAT sticks.
Then I simply 'compute' the 'UTC' for any file, which should no longer differ between
January and June.

B.t.w.: think of the following situation with FAT involved:

On 12th of May I create a file at 10:00 on NTFS and record its UTC as 08:00,
then I copy it to FAT, where it will have 10:00 as a timestamp, but must be recorded
as 09:00, because in November the file on NTFS shows 09:00, corrected to 08:00,
but on the FAT it still shows as 10:00.

I just gave up. Stupid NTFS.

P.S.: I just must record all file times, or I must browse all the file system any time
I want to check or backup.

;JOOP!
0
 
CEHJCommented:
>>Stupid NTFS.

It's actually FAT that's stupid: you could only know the correct timestamp is you knew where(!) it was created ;-)
0
 
sciuriwareAuthor Commented:
OK, how about: both are stupid, only UNIX filesystems make sense.
;JOOP!
0
 
sciuriwareAuthor Commented:
OK, formatting a USB stick right away is not possible without changing global XP settings,

but the MSDOS command                       convert H:/FS:NTFS
 works very fast.

Bye.

;JOOP!
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

  • 10
  • 9
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now