Did someone break GetTimeZoneInformation in XP?

by Michael S. Kaplan, published on 2008/06/29 13:21 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2008/06/29/8667900.aspx


Kim Gräsman asks via the Contact link:

Subject: GetTimeZoneInformation changed on XP?

Hi Michael,

I haven't been following your blog closely, but I was recommended on a
newsgroup to ask you about this. Hopefully you can help me out, or direct me to someone who can.

It seems GetTimeZoneInformation has changed recently, and broken its documented behavior -- as I understand it:

1) If Automatic DST adjustment is turned off, GTZI is documented to return TIME_ZONE_ID_UNKNOWN
2) If Automatic DST adjustment is turned off, GTZI is documented to return a struct containing StandardDate and DaylightDate with the wMonth member set to zero.

For some reason, on all of our XP machines, GTZI does the following instead:

1) If Automatic DST adjustment is turned off -- returns TIME_ZONE_ID_DAYLIGHT (even though we're still in standard time)
2) If Automatic DST adjustment is turned off -- returns a struct with both wMonths set to October (10), which is, incidentally, the month where DST turns off here.

I'm absolutely positive that this behavior has changed recently, though I can't say when, I stumbled upon it the other day.

Now, a question: is this likely due to a code change in GetTimeZoneInformation (i.e. has the code been updated for some XP patch) or can it be caused by the recent updates to the time zone database? I'm trying to get an idea of where to start looking...

I'm in the "(GMT+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna" time zone, FWIW.

Many thanks for any ideas,
- Kim Gräsman

Obviously there has been a great deal of interest in time zones lately.

If anything was ever going to change that was going to break some specific behavior while trying to fix the larger problem that

then we are definitely in the "right" time to see such a change....

Combine that information with the Second Tester's Axiom:

Axiom II: If someone changes it, they probably broke it

and suddenly problems seem more likely -- and I'll take this bug report as more authoritative (off the top of my head) than assurances that no such bug exists. :-)

I don't know of a specific change to the XP-level GetTimeZoneInformation that would change the return value this way for the non-DST-timezone case, and I would be curious if Server 2003 repros this, or whether Vista SP1/Server 2008 show the same behavior -- not just in GetTimeZoneInformation but also in the newer GetTimeZoneInformationForYear or GetDynamicTimeZoneInformation functions.

I'll forward this blog and the forum note to some of the time zone movers/shakers to see if anything pops....

A smattering of prior blogs from this Blog about time zones:



This post has no sponsor


# Kim Gräsman on 1 Jul 2008 9:29 AM:

Hi Michael,

Thanks for the shout-out.

Here's a minimalistic repro case, should someone feel the urge to try it:

--

#include <windows.h>
#include <iostream>
using namespace std;
static const char* RetvalNames[] = {
 "TIME_ZONE_ID_UNKNOWN", 
 "TIME_ZONE_ID_STANDARD",
 "TIME_ZONE_ID_DAYLIGHT"
};

int main(int argc, char* argv[])
{
    TIME_ZONE_INFORMATION tzi = {0};
    DWORD retval = GetTimeZoneInformation(&tzi);
    cout << "Return value: " << RetvalNames[retval] << " (" << retval << ")" << endl;
    cout << "Daylight start month: " << tzi.DaylightDate.wMonth << endl;
    cout << "Standard start month: " << tzi.StandardDate.wMonth << endl;
}

--

It should say:

Return value: TIME_ZONE_ID_UNKNOWN (0)
Daylight start month: 0
Standard start month: 0

When we originally had this problem, I checked on Vista (pre SP1, I think) and it worked as expected. Haven't checked other platforms.

Cheers,
- Kim

# Gert-Jan on 1 Jul 2008 9:44 AM:

Boy does this sound familiar! I already ran into these problems 7 years ago, and nothing has changed it seems.

My first assumption was that turning off automatic DST adjustment would do only that: stop Windows from automatically adjusting my system clock when switching from DST and back.

When I turn the automatic adjustment off I don't change timezones and the same DST rules are therefore still valid, so I expected Windows would still know about DST even with the automatic adjustment switched off.

In practice it completely disables DST, causes GTZI to return bogus data and its behavior doesn't follow the official documentation anymore.

I happened to have access to Microsoft support at the time (Win2k days), and the answer I got was that "the internal structures do not have a boolean that says that daylight is enabled/disabled. All they carry are some strings and time values, so to "disable daylight" you set the daylight and standard to the same values."

So for me this weird behavior is not recent, since it has been broken since Win2k (so including XP); it actually only worked right under Windows98 :-/

At the time I already asked for a documentation update since GTZI returning TIME_ZONE_ID_DAYLIGHT the whole year round with bogus transition dates is just wrong and doesn't match the documentation, as mentioned by Kim. But apparently nothing happened since...

But for me the main problem is that disabling the automatic DST adjustment impacts GTZI for no good reason.

The on-line help for the automatic DST adjustment setting still says "If you use more than one operating system, make sure that only one of them automatically adjusts for daylight saving time."

What it doesn't tell you is that disabling the adjustment in Windows has nasty side-effects...

# John Cowan on 1 Jul 2008 3:44 PM:

If only you people didn't suffer so badly from NIH and would use the Olson time zone data and library, like everyone else on the planet Earth.

# Michael S. Kaplan on 6 Oct 2008 6:03 PM:

There is a large installed base that would be broken by that move to support what "everyone else on the planet" uses, thus such moves should only be taken lightly by people who are willing to let large pieces of the world fall down in ways that make the DST 2007 problems look like a knee scrape....


go to newer or older post, or back to index or month or day