I just spent all day yesterday, along with a co-worker, tracking down one of the more heinous time calculation bugs I've ever seen. If you're a programmer, you probably already know about the Daylight Savings Time change that is occurring in this year of 2007. This is sending a shock wave of problems through the IT industry on a scale of which we probably haven't seen since Y2k. Everyone is having to update code that calculates when DST begins and ends.
In short, Microsoft is either in a very tight spot, or they screwed up big time. With the new calculation of DST, any year previous to 2007 now has the potential to show the wrong time! Here is a quick example.
This page is using JavaScript within the viewers browser to calculate dates. You will notice that if you are viewing this page from Vista, or a Linux based OS, that all the dates are displayed as expected. If you're on a Windows XP or earlier OS, the middle two dates will show as being in DST when they should not be:
Wed Mar 15 00:00:00 CDT 2006 <- Um, not quite yet actually. CDT doesn't start until April 02, 2006 02:00.
This is because MS OS' previous to Vista can only store one set of DST rules. So when you installed that cool new patch that fixes 2007 and future dates, you break every year previous to it. Nice. Granted this only crops up in past dates between the previous DST starting time, and the new one. I.e. between 2007 and 2006, this is between March 11 and April 2. See another conversation on this.
This is going to cause problems until it is fixed. Hopefully MS can get us something quickly, but depending on how deeply the OS is affected by this - they could have a serious issue on their hands.
3 comments:
So, Brian... what was your stragegy for COR? We'd already figured out that the patch was not really a fix... and could screw things up between install and March 11. I've been expecting a fix from MS... but now I'm not so sure.
What to do?
Brian's responsibility is limited to web stuff. So I'll take a crack at the answer.
My prior reading on this suggested it was a matter of applying patches, like any other Microsoft patch. So I wasn't worried. Now we're just over a week out and I'm discovering it's much more. We're already having users notice appointments within the affected date range are off by an hour.
Microsoft provides a piece of software that will go through everyone's Exchange calendar and fix the appointments in the date range from March 11 to April 1, but it simply changes the UTC, knowing that Windows will render it incorrectly. How's that for a fix?
Ian, our network admin, is having trouble getting the thing to run. It gets to a certain user's mailbox and errors out. Are we having fun yet?
Bottom line: our strategy for COR is to work through it as best we can, based on tools and advice provided by Microsoft. But we're finding their tools and advice to be inadequate.
Yeah, I concur with Clif here. On the web application side, we can get around it by using a Mac or Linux box. I'm also involved with the WEC team developing software, which is where we came across this problem. http://webempoweredchurch.com
Our suggestion for users of the software is to input a wrong date to fake it out, or use a Mac or Linux box. Neither are good options. Like Clif said, we're just working with it the best we can and letting people know the problem exists.
If someone out there is reading and knows more, we'd love to hear from you. Thanks!
Post a Comment