I received a question from a customer who had applied the Windows OS update for daylight saving time in 2007 (kb 931836). They said that they noticed that after the update was applied, events in past years also adjucted to the new DST rules as well. “How does Windows handle historical events in software applications with daylight saving time updates?”
We will release a brief document that explains how documents and computers use and display time, and how Windows is impacted. Until then, here’s a brief explanation.
Overall, Windows software applications that handle time stamps typically store those time stamps in Universal Coordinated Time (UTC). The advantage of UTC is that it is universal and invariant; it is not subject to local time zones or daylight saving time (DST) changes. However, UTC is not a format that is meaningful to most users: imagine if you (like the BBC World Service does for radio programmes) referred to all events on your calendar in GMT… that might be a bit difficult to manage when talking to other people not used to GMT.
There’s a similar issue with computer software: most events with time are recorded by software and the computer in UTC, so computers convert UTC time to local time to make it easy for local users to understand. The conversion in Windows is based on two factors: first, the time zone as designated by the user; and second, whether or not DST has been selected in the Date and Time control panel.
So, the change in DST should not in general affect the historical time stamps as recorded in UTC in documents, but it may impact how time stamps are interpreted (and therefore displayed) by the Windows operating system (folders, document properties like creation or edited times) and certain applications for a few weeks in 2007 as well as in previous years. We refer to these additional four weeks of DST (March 11, 2007 to April 1, 2007 and October 28, 2007 to November 4, 2007) as the ‘extended DST period’ – that’s the few weeks in between the second Sunday in March and the first Sunday in April. We refer to the equivalent dates in previous years as ‘previous extended DST periods.’
Many Microsoft and third party software applications already take this into consideration. For instance, time stamps in “track changes” and inserted comments in applications such as Microsoft Office Word, Excel and PowerPoint will record the time based on the time displayed by your Windows operating system clock. (There may some ‘home-grown’ line of business applications that don’t do this use the local system time rather than UTC.)
After you have applied the latest Windows XP time zone update, these time stamps will display the correct time for items modified during the extended DST period. Additionally, no changes are made retroactively, so time stamps in previous extended DST periods will also display correctly.
In Outlook, past calendar items that occurred during these previous extended DST periods may be off by an hour, as Outlook derives time based on the time zone and DST selected.
Here’s an example of the impact on displayed time stamps and what you’ll experience when you view document properties in Windows XP. Once you have applied the Windows time zone update for 2007, files created during the extended DST will display the correct ‘date modified’ time in file properties. However, date modified time stamps that fall into previous extended DST periods (e.g., March 12, 2006 to April 2, 2006) will also be shifted by one hour. In this example, the document was created on March 20, 2006 and saved it at 7:28 PM. After you apply the Windows update, the file created last year will be erroneously updated and will show a time stamp in its ‘date modified’ properties of 8:28 PM (see below).
For more info on the impact of DST, also see my reference to the article in IT Pro Magazine on daylight saving time, and Raymond Chen’s articles on “The Date/Time control panel is not a calendar” and DST for versions of Windows prior to the release of before Vista in “Why Daylight Savings Time is nonintuitive.”