Every time change (now daylight to standard), the timestamps on all files on
my 3 hard disks (1 local, 2 networked) show the new time (i.e., 1 hour less in
the Fall) BUT those same files on my removable disk (Cruzer 8GB thumb drive)
still have the “old” time (i.e., 1 hour more in the Fall). This causes the
entire set of files to miscompare when compared based on time (and I have to
recopy all files (GBs) to the removable disk. Been happening for years and have
never seen an explanation.
Years ago, one of the ways I took work home was to use an external disk and a
file copying tool that copied only files that had changed, using the time
stamps to determine which files should be copied.
Once a year everything changed and all files were copied, and once a year a
bunch of files would be copied in wrong direction.
And, like you, it happened every time we left and entered daylight saving
time.
]]>
In short, it’s all about the file systems.
Or, rather, that the two disks containing the files being compared had differing file systems – NTFS versus FAT.
In the FAT file system, when a file’s timestamp is written it uses your local time. So if it’s 8:32AM and you write your file, then it’s “8:32 AM” that gets written to the disk.
In the NTFS, all timestamps are written in Coordinated Universal Time or UTC (roughly equivalent to Greenwich Mean Time, GMT). That means if it’s 8:32AM, and you’re in the U.S.’s Eastern time zone (ET) which is UTC -5, then the actual time written to the disk is 13:32 UTC. When the file’s time is displayed, then of course, the time zone is once again factored in and the time of 8:32AM is shown.
Here’s the rub: Eastern time, or more correctly Eastern Standard Time (EST) is UTC-5 unless you’re in daylight saving time, in which case it’s (“spring forward”) UTC-4 – Eastern Daylight Time (EDT). During daylight saving time, the same file’s timestamp will be displayed as 9:32AM – that’s the time it was written had daylight saving time been in effect at the time it was written.
And yes, I’ll happily admit it’s confusing as all get out.
But here’s where the fun starts.
To continue with our example, let’s assume you copied a file from an NTFS formatted disk to a FAT formatted disk in the Eastern time zone while daylight saving time was not in effect. The time stamps are stored differently – 13:32 UTC on the NTFS disk and 8:32 AM on the FAT disk – but they display the same; when displayed the NTFS time is adjusted by your time zone, subtracting 5 arriving at the same 8:32 AM.
Now daylight saving time arrives.
The time stamps are still stored exactly as they were – 13:32 UTC on the NTFS disk and 8:32 AM on the FAT disk – but they no longer display the same; when displayed the NTFS time is adjusted by your time zone, which is now -4 with daylight saving time in effect, and the timestamp on the NTFS drive appears as 9:32 AM.
The files appear different.
Even though they’re not.
And a file copying utility that uses the timestamps to see which is newer will think they’re different and copy the “newer” one onto the older one.
| Time of year | File Creation Date | NTFS Displays | FAT displays |
| Standard Time | 01/01/2009 8:32 AM Standard Time | 01/01/2009 8:32 AM | 01/01/2009 8:32 AM |
| Daylight Saving Time | 01/01/2009 8:32 AM Standard Time | 01/01/2009 9:32 AM | 01/01/2009 8:32 AM |
So, what do you do?
To be completely honest, I simply lived with it for several years.
Then I converted the external drive I was using to NTFS and the problem went away.
These days that’s probably the most practical solution in most cases.
Your response to the subject was great, no one I’ve asked before had any idea. Yours is a site I will visit often.
Thank you very much!
Nice post- simple explanation for a maddening problem. Add the complexity of EXIF photos and working in Australia / US where the time is about 12 hours opposite. I can’t tell you how many photosets I have where I’ve taken photos from 10am to say 4pm and they get split into Tues 10pm through Wed 4am.
Another fun project:
Save a file to a FAT device on your computer. Change your timezone (or go to another computer in a different timezone) and the date/times will no longer match.
Le sigh.
Leo, out of curiousity, do you know of a Universal File Format other than FAT that supports UTC and works between Linux, Windows, and Mac?
20-Nov-2009
One other, rather obvious solution: If you can tolerate your pc’s time being 1 hour off for six months every year, would be to go into your control panel (Time Zone tab in Date and Time Properties) and un-check the ‘Apply Daylight Saving’s Time’ box.
26-Nov-2009
I wondered about the GMT/NTFS part. I generated a notepad file, checked the timestamp..it’s PST. The machine is XPP, HD is NTFS.
I’d not heard the GMT timestamping of files written under an NTFS. The file I just saved doesn’t show that to be so.
I’m assuming ‘timestamp’ to be the time shown in a Windows Explorer window..or in the properties window of a particular file
What am I missing?
Thanks!
26-Nov-2009
I DID read it.
…just not very good! I KNEW I was missing something.
The third time through I see what I’d missed.
The Helen Reddy Sped Reddin course strikes again!
Thanks, Leo.
Some synchronising tools (e.g. GoodSync) will ignore apparent time stamp differences of exactly one hour. Useful if you need to sync between FAT32 and NTFS drives.
I found a small utility called Righttime (try googling it), which is free and relatively simple to use. It will change the timestamp of the files you indicate to either make them one hour ‘older’ or ‘younger’ — the trick is knowing what to use when.
The frustrating problem with the seasonal time change is that EXISTING files get one hour taken off every time we switch to Standard Time from Daylight Savings Time!
In other words, ALL files created (I meant, ‘modified’, in Microsoft Newspeak) during Daylight Savings Time get one hour subtracted (in Windows Explorer and any application using the File System) when we revert to Standard Time!
How stupid is that!!! Why can’t Windows Explorer show me the real time for files modified during Daylight Savings Time? Any idea how this obnoxious behaviour can be corrected?! I can’t seem to find a solution online anywhere!
This problem also affects the command.exe ‘dir’ command and 7-zip listings of ISO files. Nobody cares what time it would’ve been when the file was created if it had been done in Afghanistan during monsoon moonlight time. People care whether the file has been modified, as indicated by whether the time that’s output to a listing now is the same as the time that was output to a listing last month. People are getting results that prevent them from making correct determinations about their files, and it’s just plain wrong.