by Michael S. Kaplan, published on 2007/01/29 08:31 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/01/29/1551597.aspx
Windows has some time zone information stored in its innards.
But Windows only lives in the now; it pays no attention to what was and what will be, even when it does know.
In the words of George Carlin, I think I'll repeat that since since it seems vaguely important.
Windows only lives in the now; it pays no attention to what was and what will be, even when it does know.
Isn't Windows just the little hedonist? :-)
Which is part of the answer to a question Benoit Houle posed via the Contact link (probably better for the Suggestion Box, but I won't quibble; no one reads my text about this anyway):
Hi, after installing patch KB928388, everything works fine for DST in the future but it does not seems to work in the past. It looks like the DTS suppose to start only in 2007 is applied to years prior to this date. So by using the DateTime.ToUniversalTime() function for 2006, we are off by one week in fall and 3 weeks in spring.
you can try it with this small C# .NET code:
Console.WriteLine("");
Console.WriteLine("MARCH");
DateTime dt = Convert.ToDateTime("2006-03-01");
for (int i = 0; i < 60; i++)
{
dt = dt.AddDays(1);
Console.WriteLine(dt.ToUniversalTime().ToString("yyyy-MM-dd HH:mm:ss"));
}
Console.WriteLine("");
Console.WriteLine("NOVEMBER");
dt = Convert.ToDateTime("2006-10-01");
for (int i = 0; i < 60; i++)
{
dt = dt.AddDays(1);
Console.WriteLine(dt.ToUniversalTime().ToString("yyyy-MM-dd HH:mm:ss"));
}
Notice how the DST should be applied on october 29th in 2006 and is applied on november 5th
NOTE: I am in Canada Standard Eastern Time Zone.
I talk to MS support people and they did not have an answer for me.
Any solutions?
Best regards Benoit Houle
Everything is behaving as designed, until and unless some future version adds the "feature" of historical time zone knowledge.
Now the .NET Framework is the one that attempts to move into the realm of using the date in question to determine how to evaluate it, as described in Raymond Chen's epic post Why Daylight Savings [sic] Time is nonintuitive, so technically the .NET Framework is the technology that is teasing here by making the promise of dynamic evaluation even though the historical data may not be there; Windows itself doesn't try to do that....
I guess the .NET Framework could be doing a slightly better job on Vista if it is using the new dynamic time zones I have mentioned previously. It might be worth giving that a try to see if it works (if not then someone should go up and report this as a bug so that it can be fixed in a future version!).
This post brought to you by ٭ (U+066d, a.k.a. ARABIC FIVE POINTED STAR)
# jondr on 29 Jan 2007 6:19 PM:
Oh, my. We have it so good nowadays, I really can't complain. In the '80s my employer bought a new minicomputer for about $350,000. We went from standard to daylight savings one spring, and there was no change on the clock. They'd forgotten to implement DST altogether. A patch came in a few weeks later.