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
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
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
DaylightDate changes meaning depending on whether the
wYear is zero or nonzero.
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”.