Windows vs. Linux File Timestamps

You'd think it would be pretty simple. When you create or modify a file, the file's directory entry on your hard disk gets a "time stamp" that records the time you created or modified it. The time stamp thus generated is useful for many purposes, such as (the purpose I was particularly interested in when I started digging into this subject) allowing automated backup tools to quickly decide when a backup copy of a file is out of date (i.e., the file has been modified since the last backup). You just compare the time stamp of the backup copy with the time stamp of the original; if the latter is newer, you need to make a new backup.

Well, believe it or not, Microsoft found a way to screw up even something as simple as this. But let's begin at the beginning; after all, there *are* some complexities involved, so we should take a look at them before passing judgment. The naive method of time stamping files would be to just read the system clock (all modern operating systems have an internal clock that is "set" from the computer's hardware clock on boot-up--nowadays, with Internet connections being so common, a computer can also query a time server, such as the one at the U. S. Naval Observatory, to adjust its hardware and system clocks) and use its reading to time stamp files. But there are at least two problems with this. One is time zones--the naive method would quickly get hopelessly confused when trying to compare the time stamps of files that were created or modified in different time zones--and the other is daylight saving time, which can create similar problems even within a single time zone.

The designers of the Unix operating system, back in the 1970's, were aware of all this, and they adopted a simple and logical system to deal with it. (Linux, as a variety of Unix, also uses this system.) A Unix computer sets its clock to UTC (Universal Time Coordinated, also known as Greenwich Mean Time, or GMT), and time stamps files using UTC as well, since UTC is independent of time zone and other such vagaries. The only time a Unix system even cares what time zone it's in or whether it's in daylight saving or not is when it displays a time (the system time or a file time stamp) to the user. Then it just uses the current system settings to convert UTC to the correct local time. Simple.

But there is a further wrinkle in connection with daylight saving time and displaying file time stamps, which has been giving me fits when I try to synchronize files between my Linux machine and my Windows machine. When displaying the current system time, converting from UTC to local time is simple, as above; but what if it's summer (and you're in daylight saving time), and you ask the computer to show you the file time stamp for a file that was created in the winter? It seems obvious that the computer should *not* include the daylight saving time adjustment when showing you that file time stamp, even though it does so when showing the current system time, and that is what Unix does. (And conversely, when showing you the time stamp of a file created or modified in the summer, the Unix system should, and does, apply the daylight saving correction even if it's currently winter.)

Now according to what information I've been able to find about the versions of Windows that use NTFS (meaning NT, 2000, and XP), the NTFS file system also stores file time stamps as UTC. So the same simple system ought to apply to Windows machines with NTFS file systems. But it doesn't. A Windows machine's hardware and system clocks are set to *local* time. That means the clocks are re-set twice a year, just like ordinary clocks--whereas on a Unix system the clocks are *not* reset (unless they are adjusted to be in sync with a time server), because UTC doesn't change from summer to winter (though the conversion from UTC to local time does). So when a Windows machine has to time stamp a file on an NTFS filesystem, it has to convert local time to UTC to do so. (This is presumably because non-NT versions of Windows, which used FAT file systems, stored file time stamps as local time plus time zone information, not UTC. Don't ask me why, ask Bill Gates.) Then, of course, the Windows machine has to convert UTC back to local time to display a file time stamp. (It doesn't when it displays the current system time, of course--wow, saving all those CPU cycles. Great.)

But wait--it gets better. What do you suppose happens when your computer wants to read the time stamp on a file that's on *another* computer's filesystem? Ignore for the moment all the possible complications involved with operating systems and filesystems that don't store file time stamps as UTC. Both Unix and NTFS do, so let's restrict ourselves to that case. Surely the obvious thing to do would be to simply ask the other computer for the time stamp in UTC, and then convert it just as the time stamp of a local file would be converted. That's what Unix does. The time stamps that my Linux machine shows me for files on my Windows machine (the two are connected via a LAN) change in just the way you would expect if I switch the Linux machine's daylight saving time setting, and they *don't* change for anything else. In particular, they certainly don't change when I change the time zone or daylight saving time setting on my *Windows* machine. Why should they? The physical time stamp on the actual file hasn't changed, and it's in UTC, so its meaning hasn't changed either.

Oh, I almost forgot--assuming that you hold your computer's time zone and daylight savings time settings constant, should the way it displays a file time stamp depend on whether the computer's *current* time is in summer or winter? As we saw above, it does depend on whether the *file* time stamp is in summer or winter, but should it depend on whether the computer's *current* time is summer or winter? In Unix/Linux it doesn't, which seems obviously correct. But apparently all these simple points were too much for the people who programmed Windows to deal with file time stamps.

So what does happen when I ask my Windows machine to display a file time stamp? Let's start with asking it to display a time stamp for a file on its own NTFS disk. The result I get depends on two things: (1) the Windows machine's time zone and daylight savings time settings (this is OK), and (2) whether the Windows machine's *current* time is summer or winter. Number 2 is a problem, as we just noted--and it's also a problem that the result *doesn't* depend on whether the *file* time stamp is in summer or winter. In other words: say I've got my Windows machine set to correct for daylight saving time. I look at the time stamps on two files, one created in summer, one created in winter. If it's summer, and I turn off the daylight saving time correction, and I look again at the time stamps for the two files, the displayed values for *both* will change! Huh? Shouldn't the *summer* file be the only one whose displayed time stamp changes? [1]

And what happens when I ask my Windows machine to display a file time stamp for a file on my Linux machine? The result I get depends on: (1) the Windows machine's time zone and daylight savings time settings, (2) the *Linux* machine's time zone and daylight savings time settings, (3) whether the Windows machine's *current* time is in summer or winter. And, just as above, the result does *not* depend on whether the *file* time stamp is in summer or winter! I won't even try to fully document here all the possible permutations and combinations and what I observe in each of them--it's just too much of a pain in the neck. But again, of the three dependencies I just noted, numbers 2 and 3 shouldn't make any difference to the results. They don't on the Linux machine, and as we've seen, there's no earthly reason why they should. And there is every reason why the *file* time stamp being in summer or winter *should* make a difference to the results, and it doesn't.

I won't try to speculate on why the Windows time stamp system is hosed, or whether the above behavior, which I observed on a Windows 2000 machine, is the same for older or newer versions of Windows NTFS. I don't really care to know. But after years and years of observing this kind of senseless behavior from Windows and other Microsoft software, I wonder how much longer it can go on. Software doesn't *have* to be this way. The only reason it often is is that users put up with it. We shouldn't have to.

Postscript

PC Magazine posted a brief article about this problem. Then a user sent in a suggested "fix", which was discussed in another article. The "fix", which basically consists of setting your Windows computer's time zone to GMT and then lying to it about what GMT time it is, is not one I recommend.

There is also this article about the more general issue of Windows setting the computer's RTC (Real Time Clock) to local time instead of UTC.

Links

This article on CPAN is mainly about a fix used in Perl for this problem, but also includes a section discussing the problem itself and its history. One interesting point brought out is that the hosed behavior of Windows under NTFS is not accidental: Microsoft wants Windows to behave this way. You do the math.

Notes

[1] - Actually, further observation shows that it gets even weirder. The behavior I described above is what happens immediately after you make the change to the daylight saving time setting. But if you then shut down Explorer and let the machine sit overnight, the behavior changes--now the file time stamps that are displayed *do* depend on whether the file's time stamp is in summer or winter. At this point I really don't have the time or inclination to do further investigation, to see if the behavior is still this weird when the system's current time is winter instead of summer, and so on. I'm just glad I don't depend on the Windows machine for all that much any more. back to text