by Michael S. Kaplan, published on 2012/03/13 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2012/03/13/10281814.aspx
One of the best specific consequences of the whole DST weirdness back in 2007 was a design decision to start paying attention to historical time zone information.
Well, it put a real cat among the pigeons for people like me mwho decided they like Windows behavior better than .NET behavior as Raymond described almost a decade ago in seminal Why Daylight Savings Time is nonintuitive.
You know, the one where he explained how "Win32 always deals with the time zone you are currently in (even if it's not the time zone that corresponds to the timestamp you are manipulating), whereas .NET deals with the time zone that was in effect at the time the timestamp was generated."
Now, even though Windows will "ignore" whether the time five months ago was an hour behind or not, it will be able to know whether it is 24 hours different because the Samoa time zone was moved by over 24 hours at the end of last year.
You know, like I described in blogs like What do Ian Anderson and Samoa have in common? They're both tired of Living in the Past! and What do Samoa and Seattle have in common? The sun won't shine on either on Dec 30th!.
Trying to combine the two notions of "I care tremendously what you thought the time was two years ago and whether it was DST or not" with "I don't care whether or not you thought it wasn't DST five months ago".
Seriously, try it.
Especially when you consider the interesting yet strange differences between system times and file times, and then throw the .NET TimeZoneInfo and TimeZone and DateTimeOffset and the like, for good measure.
Then throw in trying to use more than one of them.
Or converting between one two or more of them.
If you think about it long enough, it will give you a headache.
A serious headache.
Oh well, look on the bright side.
When we first made the Samoa fix, in MSKB 2633952 (December 2011 cumulative time zone update for Windows operating systems), there was a bug.
It seems they forgot to add the historical info, which required them to release MSKB 2657025 (Update for 2011 calendar history in Windows operating systems), to fix the problem.
However, if you wanted to take a moment to think of those care free days before everyone decided to start over-thinking the plumbing about time zones before clicking on that update, I shan't fault you.
Those were simpler times.... :-)
John Cowan on 13 Mar 2012 4:15 PM:
That explanation about local-to-UTC and UTC-to-local time converters not being inverses (on Raymond's blog) doesn't make any sense. If you have a local time between 2 AM and 3 AM on "spring ahead" day, you made a mistake writing down what time it was. It can't be converted to UTC because IT DIDN'T EXIST.
And if you don't care whether it was DST five years ago or not, why care what time zone it was five years ago at all? Just render everything in current time.
Simon Buchan on 13 Mar 2012 6:07 PM:
Gah. I got a headache just reading those "notions". I can't fit even one of them in my head, and I humbly consider myself more informed than most developers working with times (for a weak enough "with").
I'm in favor of the Russian abolition of Daylight Saving: it may not fix all timezone woes, but it should help reduce future ones!
Henry Skoglund on 13 Mar 2012 7:23 PM:
I was hoping that Protogon/ReFs had an extra timefield in its metadata, i.e. current offset in seconds from UTC *at the time the file was saved*, but I haven't seen it yet.
I mean, instead of switching all your files on C: to another time when you transition PST/PDT, like Win32 does, or trying to recreate the historical timezone in effect at file save, like NET does, one thing that could save you from going bonkers (unless you're a Time Lord) is to include with each and every file's metadata the current UTC offset in seconds, both for the last modified date/time and the creation date/time. NTFS cannot be changed now but perhaps still possible with ReFS...