i hate the dst

Well, I shouldn’t say that I despise Daylight Savings Time – not at this point in my life anyway. When I was young, I hated being forced to go to bed while it was still light out. Maybe that’s why I prefer the winter months now? Child psychology aside, what I really don’t like is the hysteria surrounding the new DST period. Those of us in most places in North America used to set our clocks ahead one hour at 2AM on the first Sunday in April, and set them back one hour at 2AM on the last Sunday in October. Due to the Energy Policy Act of 2005, we now set our clocks ahead one hour on the second Sunday in March, and set them back one hour on the first Sunday in November.

Being the geekboy that I am, I should mention that plenty of software and hardware vendors have offered DST patches to correct the clocks and time functions of products that automatically adjust for DST or perform date calculations. These patches are often more of a convenience than anything else. Because I patched up my Windows computers, I know that when I wake up tomorrow morning, their clocks will have adjusted accordingly. Yay? Sure, yay. Yet I’ve recently spoken with some enterprise software vendors who are spreading FUD like mad cheddar. I’ve been told that their enterprise applications will cease to work, lest money be spent to purchase their current version. Honestly, what sort of application is that concerned with timezones (I’m omitting the kinds of apps like the ones that keep planes in the air)? At an operating system level, time is kept in Coordinated Universal Time. Local time is merely an offset to keep people happy, and with good reason. Here in the eastern time zone, we’re always 5 hours behind UTC in the winter and 4 hours behind in the summer – that’s local time. If we’re talking enterprise apps, I would think that anything that logs date/time stamps would do so in UTC, and when date/time is to be displayed to a user, then use local time. In the .NET world, it’s as easy as:

// UTC time
System.DateTime dtUTC   = DateTime.UtcNow;

// Local time
System.DateTime dtLocal = DateTime.Now;

There’s no need to roll your own time zone offset. I’m assuming that in the Java world, J2EE has something similar (correct me if I’m wrong). Then again, if all vendors where honest with customers, that wouldn’t sell as many licenses/units.

Also, because we’ll have more daylight, the logic is that we’ll rely on less electricity to light our homes during the summer. With CFL and LED light bulbs, I’d bet that keeping a house lit with those would be require far less electricity than what’s required when air conditioners are running. Just a thought…