|Gary Olsen, Contributor|
Yep – that's right. I was recently contacted by an admin who had noticed that events and files had had their time stamps changed by one hour when the DST changes went into effect on Nov. 4 (GMT +1). To be honest, I'd never noticed if this was the case, but it did make sense.
Remember that each computer has a "reference clock" that runs on UTC time. This is unaffected by the time zone adjustment. What you see in the Date and Time properties UI is the time zone adjusted "local time." It is this local time that event logs use to register time stamps of events, record the creation and modified dates of files, and entries in other logs. This helps establish times of events relative to the actual local time, and you don't have to calculate when it really happened.
However, when the local time changes, it will change the time stamps for past events. That was disconcerting to this administrator because events were actually one hour off from when they happened. So if a server rebooted at 10 a.m. on Oct. 14, that event will read 9 a.m. if you look at the time stamp after Nov. 4. It seemed to mess everything up.
It turns out that this is by design in Windows. If you change the local time, then it only makes sense that those time stamps also change. Further, suppose an event occurred Nov. 4 at 1:30 a.m. Then at 2 a.m., the time zone moves the clock back to 1 a.m. Another event now occurs at the new 1:30 a.m. -- it would actually be 2:30 a.m. if the time zone change did not occur. So now you have two events at the same time that are, in fact, an hour apart. By changing the times relative to the current local time, they all fit.
This is easily reproducible. Create a file and save it. Note the time stamp. Then change the time zone in the Date and Time utility, and you'll see that the time stamp on the file changes by the delta that you modified the time. Change the time zone back, and the time stamp changes back.
This is explained quite nicely in an MSDN blog that describes how it works and, thus, verifies that it is expected behavior.
Although it may seem that this messes up events for auditing, it really does make perfect sense because the time stamps will always be relative to current local time. That's the way it works and you can't change it.
Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers. Gary is a Microsoft MVP for Windows Server-File Systems.