Wasting Energy on Energy Preservation

The ridiculously myopic Energy Preservation Act of 2005 mandated that Daylight Savings Time - a predictable fixture for longer than I've been alive - would be modified to start sooner and end later.

Hilarity ensues.

Unlike the Y2K issue, EPA2005 approached rather unexpectedly. Much like Y2k, however, it highlights the remarkably poor, closed-minded job software companies do at planning and developing software.

As one might expect, nothing is immune from the DST change. And, as cynics would bet, patches for this issue wouldn't be available until mere months before the change was to take place - spinning IT departments into instant crisis mode. "Yes, we would have fixed this sooner, but *none* of our vendors got it right." Keep in mind that this was the Energy Preservation Act of 2005. It's now firmly 2007, and we're just now in possession of all the patches we require.

So, again, the entire IT industry looks like a bunch of children who couldn't plan their way out of a wet paper bag. This should be a very, very easy problem for IT departments to fix. OS vendors would simply issue patches that contain the new DST start and end dates...we apply them...end of story.

W r o n g .

Turns out that very few applications rely on their host OS to tell them the correct time.

. . .

So, the fun begins. The insidious plague - the scourge of mankind - the boil on the face of IT known as Java - keeps it's own time. Each JRE keeps it's own time. And as you've read here before, seems like Sun has never embraced "backwards compatibility" as it applies to Java. So in short, just about everything we have that runs on Java needs it's own patch. Nice.

It gets worse.

Novell GroupWise needs patches too. Again, it runs on servers whose time MUST be kept in synchronization with one another. I understand that WebAccess might need to know the new parameters....actually, no I don't. I also don't understand why the GroupWise SMTP server, or GWIA, can't just ask the OS "Hey, what time is it?" now and again. I don't understand why the GroupWise CLIENT, which runs on WINDOWS, which KNOWS THE TIME, can't figure out from the OS itself what time it is, let alone the DATE.

It all confuses me. It's all ignorant. It's an embarrassment for anyone other than an OS vendor or hardware platform vendor with a proprietary embedded kernel (like Palm, RIM, etc) to require patches for the changes to DST. If you have custody over an IT shop of any size and haven't figured out NTP, you're a bozo and need to turn in your resignation right now. If you're a software developer and think that YOU know better than anyone else how to track time, you need to smash your computer with a sledge hammer and never ever touch one again. The sooner, the better.

In the mean time, those of us whose laps receive the problems and challenges that nobody else has the guts or brains to tackle - the enterprise IT professionals - will dutifully go about cleaning up someone else's mess....again.