Sorting it all Out

MS Released a tool a few days ago which may help affect users

http://www.microsoft.com/downloads/details.aspx?FamilyID=e343a233-b9c8-4652-9dd8-ae0f1af62568&DisplayLang=en

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?

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.

So I wrote a post and set it to go live at 12:01 am (an hour before this one is set to go live), yet

Kim Gräsman asks via the Contact link: Subject: GetTimeZoneInformation changed on XP? Hi Michael, I haven't

PingBack from http://www.jeffhung.net/blog/articles/jeffhung/985/