There is lots of chatter lately about the whole Daylight Savings Time “blah” where “blah” is whatever it is you want to call it – hubbub, scare, whatever. I don’t know what to call it other than blah but it certainly is causing far more trouble than its worth. I am getting pinged with quite a few questions about it in email to me personally, email to me at work, newsgroups, listservs, everywhere.
Let me start off with the three biggest questions…
1. Will AD replication break if
a. No DCs are updated?
b. All of the DCs are updated?
c. Some portion of the DCs are updated?
2. Will Kerberos authentication break under any of the conditions listed in 1 but for machines, not just DCs?
3. If I update a DC will that fix the time on all of the other machines or do I have to update every machine?
The answers are
1. No, not for any of those subitems.
2. No, not for any of those subitems.
3. No, you need to touch every machine that you want the time to be displayed “properly” on.
So what does this last sentence above mean? The main thing to keep in mind is that computers are not people. They don’t need to see time in a local offset, they use what is called Coordinated Universal Time, this is also known as Zulu time. Zulu time does not have a DST offset and is equivalent to GMT (but not BST – British Summer Time). All computers use UTC so a DC in Detroit has the same internal time value as a DC in Canberra, although they can both be set to display a different local time to user based on the DST and TZ settings of the machine. Again to restate the main point, TZ and DST are for humans, not for computers.
The only time having incorrect TZ and DST settings can hurt you at a system level is when trying to set a new time manually… The time will be input in local time and then the incorrect TZ and/or DST values will be used to convert to the internally used UTC value… Microsoft could have easily gotten around this by having people input the time in UTC because the API call that sets the time actually requires UTC… however, doing so would just show most people don’t have a clue what UTC is.
Oh… Something that confuses some folks… The Event Log and the File System and AD all log times in UTC, not local time. AD doesn’t surprise folks so much because there are mechanisms to easily see the time stamps in UTC, the Event Log and File System are a little more surprising because people never see those items displayed in anything but local time.
With all of this being said, there actually is a good reason to make sure that DST and TZ settings are correct. Poorly written applications that use local time for calculations instead of UTC. I won’t name any specific apps but if you google you will likely read about several very popular apps that have issues here.
Gary Olsen is one of the folks with whom I previously discussed this topic at length, he took the time to write up the results and published them in a Tech Target article. You can read the article here.
joe
Very good explanation Joe, and nice job on the article with Gary.
I understand that Microsoft is taking a hardline with hotfixes for W2K but I wish they would have made an exception for this one and released it to the public. To me it is moves like that that give them a bad name.
This is the very reason why time in aviation is UTC or Zulu-based. It cuts out any confusion, except amongst the most dull. And they shouldn’t be flying aircraft.
Wish it were the same with Windows administration.