I'm sorry, but Microsoft does not get time zones

by Michael S. Kaplan, published on 2007/02/05 17:45 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/02/05/1606868.aspx

Okay, it's official. We still don't know anything whatsoever about reasonable customer time zone experiences at Microsoft.

Now this is the communal we that I am using here, as I take all 76,003 full time employees (exact number may be wrong, but I am not in HR) and say for the record that if the single most visible application we provide in relation to time zones gets it wrong (Microsoft Outlook), that we are getting it wrong as a company. No matter how many people are doing it right, this is just way too lame for words.

In the meantime, I can't claim to officially speak for over 70,000 people in any legal/moral/ethical/social/educational/professional/veterinarial sense, but I'll do my best.

With America spanning a few timezones itself it's strange that Microsoft just doesn't get it.

The setting up of a non-US machine might be an eye opener for Microsoft engineer. The amount of times you have to choose UK/English during an install of XP must be at least 4-5 times.

Maybe timezones and setting regional details should be a team itself spread world-wide - is this how localisation is currently handled?

[)amien

Microsoft has made a mess of it for years. We had a Windows CE O/S where daylight saving didn't work in the Southern Hemisphere, and 2 releases of Windows Media Player (v9 and v10) where all tracks labelled in a timezone outside of the Americas (actually every timezone in GMT or forward of GMT) have release year altered by a full year.

None of these releases was ever patched, although frequently reported. We had to wait for years for full new releases for the issue to be addressed.

The fall out over this DST timezone change is hitting us hard despite our software doing things right (so we thought) over the last 10 years.

Our software stores all times in UTC, just like Windows NT does, and converts them to a presentation time using the _tcsftime() (strftime) in the CRT. Everything has worked great for us as it has correctly calculated all historic times correctly, until now.

Apparently we were naïve, as now historic times are calculated incorrectly due to Windows inability to calculate the correct DST times from previous years, including 2006! You can try it for yourself, by changing the system clock to March 13th 2006 on a Windows XP machine (or 2000 machine with manual registry patch as suggested in KB914387). Vista gets it right, but as that represents < 0.1% of our install base it's not much consolation at the moment.

As part of the research to this problem I discovered that new registry entries where supplied as part of this "patch". There is a new registry subkey called "Dynamic DST" which appears to have a year corrected formula as mentioned in KB928388 and described in the MSDN information for DYNAMIC_TIME_ZONE_INFORMATION http://msdn2.microsoft.com/en-us/library/ms724253.aspx, however this new key appears to be there on XP/2000 merely for a) grins b) confusion c) consistency with Vista that actually uses it.

My countdown for finding a working solution is growing short, and all kinds of nasty hacks have been crossing my mind. The only workable solution that I can think of so far involves modifying our software to change the TZ environment variable to disable daylight saving and doing a manual calculation using the newly found registry setting by writing an XP equivalent of GetDynamicTimeZoneInformation().

Any and all suggestions welcome.

-Chris

P.S. Yes I did think of lobbying the government to abandon DST and it's questionable value but I discovered that politicians don't do anything unless they are politically motivated to do so.

Then why did they bother to set about "correcting" this on Vista? Obviously DST times in the US haven't changed for 40 years hence there hasn't been a local need. Had we sold any of the software to Israel or other country that changes DST on a regular basis then obviously I would have caught this limitation earlier.

Vista understands that for 2006 the dates for DST where April 2nd to October 29th (and so on for previous years) and that 2007 is March 11th to November 4th. Why wasn't this intelligence retrofitted into XP? Why bother having the new registry keys if they go unused by the operating system?

Actually, this has been broken for a loing time. We are finally trying to do something about it, but there is more to do here, obviously (as I have pointed out in other posts).

Claiming there was no problem previously is just wrong, as this HAS been a problem for a long time.

I assume the new reg keys were added to the old platform to make the patch easier to run; they are just ignored on earlier platforms so they do no harm?

I cannot speak as to why nothing was retrofitted into earlier versions, it wasn't really up to me to decide though. :-)

I wasn't claiming that it wasn't a problem previously, just that it had never been a problem for us do to our limited deployment in US and Western Europe. :-)

As those new registry settings are now documented in MSDN do you think that would be a reasonable "global" means of calculating DST historically? I don't like reading such registry entries directly, but it's the only way I can see to calculate time historically and globally.