DST and Me (also, Microsoft Screws Up)
I
have long had a love-hate relationship with Daylight Saving Time.Despite my love of snowboarding, summer is by far my favorite season (and the solstice my favorite day of the year). As Alicia Bridges sang, I love the night life--but I love the late evening summer sun even more. In the days when I used to play a lot of ultimate frisbee, I cherished the month or so a year when the combination of long summer days and DST until nearly 9.
And to celebrate the first workday of DST (and to keep Robert Karl from bothering me about my carbon emissions), I was elated to ride my bike to work yesterday.
But my relationship with DST isn't all roses and lilacs.
At my old company, Energy Interactive, I was tasked with designing a database that stored lots of time-series data--electric usage metered every 60, 15, 5, or 1 minute. The database had to be efficient, performant, and had to store data and retrieve data from different time zones.
And, thanks to the wonder of Daylight Saving Time, it had to deal with one 23-hour day and one 25-hour day per year. That wasn't such a big deal, of course, because I did what any right-thinking database designer would do: I stored all of the data based on GMT. GMT doesn't change, GMT doesn't have 23-hour days, GMT can help you through all sorts of time zone issues. The only trick is that you have to translate any local times into GMT when you import data (and back again if you're going to display it, bill on it, etc.).
The modules I wrote back then were heavily dependent on the time functions built into the Microsoft Visual C runtime library. They were sometime a pain to work with (especially with differing time zones), but they were invaluable.
This year, however, my relationship with DST took a decided turn for the worse.
As everyone knows by know, the Energy Policy Act of 2005 decreed that the start and end dates for Daylight Saving Time were changed this year--that meant that my wife, who still works at my old company and had the grave misfortune of inheriting my old code, was responsible for updating all of the modules to function correctly with the new definitions of DST.
It didn't seem like a big deal, right? Microsoft would release a new version of MSVCRT.DLL, she'd perform some testing to verify it, and everything would be peachy.
Well, it didn't work that way. Over the last few weeks, Microsoft had released patches to all of their operating systems, and a patch to .NET (albeit a buggy one)--however, MSVCRT.DLL wasn't updated.
Cindy played a game of chicken with Microsoft, hoping that eventually they'd release a new version.
Finally, last week, she blinked. She gave up hoping that they'd release a new MSVCRT.DLL, and she spent every night last week coming up with her own fix: writing code that would ensure that, for all time zones and for all years, her software would work properly.
And then she came into work on Monday and found this: On Friday, Microsoft had released a patch to MSVCRT.DLL.
Yep, a full 36 hours before the DST event.
What does this mean? It means that now she may have to undo her code changes (she tried to anticipate this in her code of course), and she'll definitely have to re-QA everything.
Microsoft, along with everyone else in America, has known about this change for 2 years. Leaving developers hanging until the day before the event was simply inexcusable.
|