Saturday, February 3, 2007

Daylight Saving Time

How many people outside the computer world have heard of the U.S. Energy Policy Act of 2005?

I have this mental picture of a bunch of very bored people deciding to have some fun by changing something that is already totally unnecessary; costing companies and municipalities all over the US a lot of money (tax payer's money in the case of government agencies.)

Basically anything with a clock, and automagic timezone change for Daylight Savings Time, will need patching. Which means that customers (or users, as they were known when I started in this field years ago!) will have various disruptions of service while we, the support folks, work evenings and weekends to upgrade firmware, Operating systems and Java (Why does every package have an embedded Java? Some of my servers have 20+ instances of Java installed! ok, that's another subject.).

Some "middle-ware" software also has a built-in time mechanism so each separate piece of software on every server has to be researched, patches downloaded, tested and then outages scheduled with customers before we take our personal time to do the actual work.

By the way this includes YOUR personal computer! If you use Windows, the Windows Update has, or will have at some point before March 11th at 2:00am, the necessary patches. If you have non-windows software installed, check each vendor for their particular approach to dealing with this man-made non-emergency emergency. I don't know what Apple is doing for this, sorry.

Apparently, from what I read, the issue is not the 1 hour difference in time, but the change of timezone from, for example, EST to DST. Client/Server software doesn't like situations where incorrect timezones are used. I recall one specific problem years ago, the mainframe had been mistakenly left at GMT but the time matched EST. My servers were set to EST with the correct time. We were implementing a package and having one of those "bang your head against the wall" moments when nothing made sense. Turned out that because the mainframe was "logically" in the UK, the software said its time was off by 5 hours from the client time! The maximum allowable time difference was 5 minutes, so therefore no connection!

So we are looking at... no backups! no job scheduler! no client/server connections.

If you take all the money that is being wasted on this effort, we could probably go a long way towards shoring up all the levies around the US that are ready to go!

As a point of interest, in some versions of UNIX there will be an overflow situation in the date/time in 2038. Get more information on that here: Unix time and Year 2038 problem

No comments: