DST is a nightmare

In my non-professional life, I'm a fan of Daylight Saving Time: I love longer evenings 7 month a year and frankly, I don't care when it's dark until 6:30AM instead of 5:30AM because I'm rarely up before 7:00AM anyway!

But as a software engineer, I've hated DST during most of my career. Before starting up appTrans Software, I was involved in industrial data logging and telemetry. You know: Recording pressures, flows, uptimes, downtimes, whatever, all day long (and other things such as automation, alarming and so on). A pretty simple job. If it weren't about DST.

The problem is that data logging devices record timestamps based on their internal clock, which knows nothing about DST. Why? Because the device doesn't know in which country it's sitting hence which rules it should apply.
Even if it knew, it wouldn't be happy anyway because it doesn't want to know how to store a yearly one-hour time hole in its table which is a simple array of numbers corresponding to 15-minutes recording intervals. Let's not even speak about the other yearly hour where the clocks rewinds to replay the last hour. Oh! and don't expect users to set the time after each transition: If they do it in the morning when showing up on duty, it's too late: There's already a few hours of mis-timestamped data. And I won't speak about the companies who have a policy for never setting DST in these devices for simplicity until someone notices a device is not on time and fixes it, using DST...

So it's up to the data analysis software running on a PC to figure out. And that's why I used to hate it: My team was in charge of writing such software!

UTC: The Ultimate Timestamp

Yeah, I know, there's Universal Time Coordinated: Time at Greenwich (the one in UK, not the one in NYC!), ignoring DST.
BTW, should be UCT, no? You won't believe it yet it's true: It's an IEC invention. IEC has two official languages: French and English. The committee couldn't decide between English UCT and French TUC. Hence the subtle(!) compromise: UTC. A bit like Mom who's fed up about you and your brother fighting for a toy: It will be for none of you!

That's true, UTC is a blessing. If the device knows it and nobody will change it (such as user reading incorrect time on the front panel). Or the device must display human-readable (a.k.a. local time, including possible DST) to passing-by human readers.
It's a blessing simply because we can now assume that the logged data uses a well-known time scale, based on an absolute reference. In C parlance, it's the amount of seconds between now and the moment where the Greenwhich people's watches said Jan 1st 1970, 12:00AM.

The idea is that DBs should contain UTC timestamps. All timestamped data providers must store UTC timestamps to the DB. All timestamped data consumers must convert UTC data from the DB back to their users' local time.
Sounds easy, doesn't it? Well, it should. If DST weren't in to make the convert UTC data from the DB back to their users' local time part a nightmare.

DST is a nightmare

First, you can't use that nice off-the-shelf charting package because it was designed to display calendar data. Hence its programmers didn't even figure they should display the time axis with a double 2:00AM - 3:00AM section some time in Spring (if you're in the Northern hemisphere) and without the said section some time in Autumn. So you have to re-implement the whole charting module yourself.
Also, converting historical data is everything but pleasant: The CRT functions will at best rely on the OS to perform the conversion. And Windows makes a bad job at converting historical timestamps: FileTimeToLocalFileTime() is wrong 50% of the time. It uses the current value of DST rather than computing the value for the given timestamp. (I don't agree with the rationale behind this behaviour).
So if you are really really serious about it, you craft your own function that converts UTC to local time, based on the GetTimeZoneInformation() info.
Until someone at the US Congress ruins your day (more than a single day actually) by changing the rule...

The very reason why MS waited until November 2006 to ship Vista :-)

I just learned from Scott Hanselman that the US will change DST switch dates as of next spring. Which introduces one more frustration: Windows does a very good job at keeping an accurate list of time zones and their switch dates rules. But it doesn't push the desire for precision up to keeping an history of rules changes. Which means that in late March 2007 (DST), when you'll want to give a look at the data from one year before (Late March 2006 - ), you'll wonder why the graphs are shifted by one hour :-(

A bad time for the guys at my previous company as well: Their devices are parameterized with the switch dates in the current time zone for the next 30 years. So they can both make UTC data logging AND use local times for the tasks that require it (Of course it's smart: It was my proposal :-)). Now, all US users will have to dial-in all their devices (they are usually used in the wild) and send new DST settings.
With Vista shipping after the 1st Sunday of Nov 2006 (DST switch date as of 2007), MS could simply make the change in the RTM version. Had it shipped before that date, they would have to keep the current DST switch date for now and post an update next year.

Oh my! I'm sooo glad I don't have to deal with these issues anymore...