Historical impact of DST 2007



DST patches may impact historical information.  The excerpt below is from a February 27, 2007 post to IT@Duke.

This information applies specifically to Microsoft systems, but other vendors' products may be affected.

See this web page for more information from Microsoft on the impact on historical data.

February 27, 2007

Perhaps, more importantly, further investigation into the pending DST changeover has revealed a few new concerns that I want to share with you. Microsoft continues to flip-flop on their responses concerning "historical data" and what impact the new DST changes will have.  Two phone calls that we made today were met with distinctly different responses -- the last confirming our belief that Microsoft's "fix" for the new DST rules will not address historical dates that fall between the new and old savings time changeover dates.  Our own testing confirms this as well.

Our understanding of the issue is as follows:

The OS stores the "rules" for DST changeover in the registry. (NOTE: these are only rules. The actual dates are computed by the
lowest level of the OS SW on system powerup.) These computed dates are passed to the SW layers above (such as .NET Framework) via the TimeDate objects/controls on which our applications are built.

Only one rule exists for each timezone in the world. This is true for all Microsoft OS with the exception of the new VISTA OS (which does not have a DST issue -- at least as far as claimed by Microsoft). The Microsoft supplied DST patch updates the "rules" for each timezone; but, as there is only one rule for each timezone, the "new" rule applies to ALL years -- past, present and future. No distinction can be made for different rules for different years.

This means that any date that falls between March 11th and the first Sunday of April for any past year will apply the "new" DST rules to that date when converting to the local time.  So a date of say, March 20th, 2006, 10 AM will be interpreted by the OS to have fallen within the DST changeover and be returned as March 20th, 2006, 11 AM, even though March 20th, 2006 was not within the DST range under the old DST rules. This can occur for any past date that falls within this range, as well as for dates that fall within the terminating DST range -- the last Sunday in October of any given past year and November 4th of that year....

What we are doing:

We have opened another case with Microsoft concerning this issue and have been told that we will hear back within 5 business days -- instead of their normal 1 -- because of the number of support calls they have been receiving...

I hope I've been able to represent the issue clearly and provide some assurance. Know that we have made it clear to Microsoft that the current "fix" state is unacceptable to us and to our customers.  Every indication we received today is that we are not alone in this stance.  The support individual we spoke too intimated that Microsoft will be fixing this problem, although no absolute timeframes were given.  We will provide you with a further update as soon as we receive information from Microsoft.