Slashdot Mirror
Preparing Your Datacenters for DST Changes?
Cheeze asks: "As I am sure some of you know, Daylight Saving Time is slated to change this year thanks to The Energy Policy Act of 2005. This means nothing to the large majority of the population except they will either sleep late one day or have to commute in the dark. To a select few, this is a crunch time akin to the Y2K fiasco, only there has been almost zero publicity recently. These select few are the ones responsible for updating the millions of computers, both servers and workstations, with the new time zone information. For newer servers, this usually means just install a patch and reboot (which is slightly more than mildly inconvenient). For older servers, this is basically an 'End of Life' declaration. Servers running software for which no patch is available will be unable to update their own clocks. This doesn't seem like such a big deal until you realize Microsoft is only offering patches for Windows XP and beyond, and Sun will not be supporting Solaris 7 and older. That should knock a large percentage of the computers 1 hour off for a few weeks this spring. What are you doing in your datacenters to prepare?"
Does this affect European time zones and summer times in any way? I presume not, and the only effect we might see is incorrect time zone in e.g. mail headers from the US, if sent from an unpatched mail server with the wrong time. Or am I forgetting something?
This should fix the problems for your Unix based machines. You can download a set of time zone source files from ftp://elsie.nci.nih.gov/pub/, these files are in the public domain. From these files you can build a full set of zoneinfo files (read the man page for zic(1)), DON'T FORGET TO BACKUP YOUR CURRENT ONES IN CASE OF PROBLEMS!! For most Linux based distros this is in a package called tzdata (which will compile the source files into zoneinfo files for you). zic(1) should put the compiled files into the right directory for you. These source files should work with most zic(1)'s, if not you may need to massage them with sed or perl. Don't forget to update /etc/localtime (or whatever other mechanism your OS uses, /etc/timezone et al) to set your localtime to the right zoneinfo file.
"...Microsoft is only offering patches for Windows XP and beyond"
They are offering support for Windows 2000, free with the right volume license, $$$ without, or they have made a manual registry hack available (which I don't have handy because I'm posting from home).
And before you ask, there are companies that still specify Win2K server and workstation to run their software, Thompson/Prometric being one of them, which is how I came to find this out.
Some days it's just not worth
chewing through my restraints.
OS patches are easy - we even built our own for patches for some obsolete unix flavors. The tzfile format is well documented and straight forward.
Our big issue is java... Whoever designed that piece of sh*t should be shot. They get the time information from the OS - so why not pull the TZ data from the OS too? But no - they rather implement it themselves... The result is beautiful. Oracle installed? You need an extra patch. Informix 10? Another patch. Websphere? Guess what - patch it separately! In the end, we had some boxes that needed 8 or more applications patched in addition to the OS.
Peter.
Clock companies everywhere aren't prepared for this. I work for one and they have to manually update all of the tower and post clocks that they have made which is in the thousands. When this last happened in the 70's there weren't embedded electronic clock systems. When daylight savings time came around you just got up on a ladder and spun the dial backwards. CBS had the best quote on this from there nightly news "do you love summer barbeque's and parties? then you'll love this" almost like they were selling the story back when the first passed the bill.
Timezones have outlived their usefulness. They were a great improvement over every village setting it's time as before timezones existed, but nowadays, you never know when something is on tv (except using an electronic program guide) and there is so much long distance interaction (ie. tech support in India, R&D division in China, etc...) that telling time has become a real hassle. If you work in a company of any scope, there are lots of meetings, and many are missed because people didn't notice the timezone, or even if they did, miscalculated the difference between their timezone and this one. Working in Canada, have to deal with: Newfoundland, Atlantic, Eastern, central, Saskatchewan (and a few cities either east or west of it that adopted the no-DST rule) mountain, and pacific time zones.
It would be a heck of a lot easier if folks would just, at a state/province, or some sort of regional level, decided that stores open at 14 Z in the winter, and 13Z in the summer (corresponding to 9am Eastern time, including DST) Store hours are already mandated, so just mandate that they change summer and winter, but do not change how people count. Define 'Local Standard winter hours' and 'Local standard summer hours.' Do not change the clocks, change the times...
I would rather do away with DST entirely, but if you must do it, it should not be done by changing the time, but rather by changing the hours, and keeping time straightforward. The best would be to forget about DST and timezones entirely, and for everyone to adopt UTC.