Public Service Announcement: Daylight Saving Time begins in most parts of the United States this weekend. Other parts of the world may change on a different day from the United States. A customer reported that they were getting incorrect values from the GetTimeZoneInformationForYear function.

I have a program that calls GetTimeZoneInformationForYear, and it looks like it’s returning incorrect DST transition dates. For example, GetTimeZoneInformationForYear(2010, NULL, &tzi) is returning March 2nd as the tzi.DaylightDate value, instead of the Expected March 14th date. The current time zone is Pacific Time.

The value returned by GetTimeZoneInformationForYear (and GetTimeZoneInformation) is correct; you’re just reading it wrong. As called out in the documentation for the TIME_ZONE_INFORMATION structure, the wDay field in the StandardDate and DaylightDate changes meaning depending on whether the wYear is zero or nonzero. If the wYear is nonzero, then the wDay has its usual meaning. But if the wYear is zero (and it is for most time zones), then the wDay encodes the week number of the cutover rather than the day number.

In other words, that 2 does not mean “March 2nd”. It means “the second week in March”.