Windows Advisor

Evolution of the File Property Timestamp

• By Raymond Chen
• 07/06/2010

In Windows 95, the timestamp information on the file property sheet showed the various timestamps in the local time zone, even if that wasn’t the time zone active at that particular moment in time. For example, right now in Redmond we are on Pacific Standard Time, so Windows 95 would show all timestamps relative to Pacific Standard Time. As a result, the timestamp on a file you created at noon on July 4 will show up as having been created at 11:00 a.m. when you view it during the winter, because noon Pacific Daylight Time refers to the same moment in time as 11:00 a.m. Pacific Standard Time. Mind you, Redmond was not using Pacific Standard Time on July 4, but the information is technically correct (if intuitively wrong).

This treatment of times that belong to "the other side" of the Daylight Saving time boundary (what outside the United States often goes by the name Summer Time) is a notable discrepancy between managed and unmanaged code. Unmanaged code historically performs conversion between coordinated universal time (UTC) and local time based on the local time zone at the time the conversion is made, rather than on the time zone that was in effect for the time being converted. One reason for this is that basing the time zone on the time being converted can result in ambiguity or times that cannot be converted. For example, during the transition from standard time to daylight time, the clock jumps ahead from 2:00 a.m. to 3:00 a.m. in the United States. A local time recorded as 2:30 a.m. would have no corresponding UTC time because there was no such thing as 2:30 a.m. locally. Even worse, a local time recorded as 2:30 a.m. during the transition from daylight time to standard time would be ambiguous, because during the transition from daylight time to standard time, the clock regresses one hour, and local time 2:30 a.m. takes place twice.

Another reason for not using the time being converted to choose the time zone is that in many cases the OS does not have the information necessary to know what time zone was in effect at some point in the past. The rules for changing between standard time and daylight time are subject to change by local governments. Furthermore, there have been countries (such as Israel and Brazil) that, until recently, did not follow a predictable set of rules but instead decided on the date for the change on a case-by-case basis. Given a point in time in the past or in the future, it is difficult (or in the case of the future, impossible) to determine with certainty what time zone is in effect at that point in time. (And good luck getting anything meaningful for points in time that predate time standardization!)

On the other hand, the System.DateTime class in managed code does its best to determine what time zone was in effect for the time being converted, opting to present something more intuitively correct, but which still may fail when presented with the unusual cases that give unmanaged code the heebie-jeebies.

Back to the evolution. In Windows 2000, the formatting of timestamps was modified slightly to say Yesterday, Today or Tomorrow for dates that were within one day of the current date. For example, instead of saying Created: Sunday, February 14, 2009, 7:00:00 AM, the property sheet would say Created: Today, February 14, 2009, 7:00:00 AM when viewed on Feb. 14. Nothing essential changed; this was just a little visual tweak to make things prettier.

In Windows Vista, the time portion of the timestamp was made a bit friendlier: If the time and date refer to the current day, then the time portion of the timestamp is given in relative notation: Created: Today, February 14, 2009, 15 minutes ago.

And most recently, in Windows 7, the file property sheet General page shows timestamps based on the time zone that was in effect at your current location when the file was created rather than based on the current time, bringing the property sheet more in alignment with the way managed code presents timestamps. Finally, the file you created at noon on July 4 will show as having been created at noon even during the winter months. This change takes advantage of the new so-called Dynamic Time Zones, which permit the Daylight Saving Time rules for a time zone to vary from year to year. This allows Windows to know that a file created on Oct. 30, 2006, in Redmond was created during Pacific Standard Time, whereas a file created on Oct. 30, 2007, was created during Pacific Daylight Time, thanks to the change in Daylight Saving Time rules in the United States that took effect in 2007.

Note, however, that the historical information that comes with Windows does not go back to years before 1987, when the rules were different still, so timestamps prior to 1987 may still end up converted incorrectly.

The result of all these changes to the interpretation of timestamps is that the same file, when viewed from different versions of Windows, may end up showing values that differ by an hour either way. The timestamp itself hasn't changed; just the way Windows presents it.

[Editor's Note: This article originally appeared in TechNet Magazine.]