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?"
Using UTC.
There is no reason for having a single server clock on non-UTC. DST, even if it was to stay the same forever, makes things a pain in the arse (once a year, an hour happens twice).
Your client should convert the timezone. For a client machine, it's not much hassle just to go into clock settings and change it.
Worst case is web-apps - the server clock should be UTC, but you still need to convert the time zone in the client-facing PHP/Perl/Java/etc code. There you're just looking at a patch to the language runtime or whatever.
To my knowledge, windows still puts the local time in the CMOS clock! I learned to ignore the clock when dual-booting windows on a machine running linux with "RTC is UTC" option set.
All of Indiana will honor DST this year. (Yet another change to have to be prepared for)
I only had to chance it once (on Win98 if I remember correctly) and there it was just an regedit call. No reboot required. At this time Win98 was switching the DST about a month wrong in MET, and I had to correct that. There is also a Microsoft Utility called tzedit, which displays and modifies the time zone rules. To have it affect the displayed time, you can go in the Control Panel, choose Date & Time and hit Ok. Then it will refresh the timezone information according to the changes you made with the tzedit.exe utility.
A more complete description of the necessary registry changes is at
Microsoft Knowledgebase 914387.
But as someone already wrote in an earlier post: Set your servers to use NTP, either from your local nameservers or from *.pool.ntp.org and have it automatically adjust for DST.
Additional details regarding minimum JVM versions required to address the timezone changes:
n tl/USDST/1 232128
- Solaris/Windows/Linux: 1.4.2_11
- HP-UX: 1.4.2.11
- AIX: 1.4.2 SR 5 20060420
- Solaris/Windows/Linux: 1.5.0_06
- HP-UX: 5.0.3
- AIX: 5.0 SR 1 20060310
References:
HP: http://www.hp.com/products1/unix/java/DST-US.html
Solaris/Windows/Linux: http://java.sun.com/developer/technicalArticles/I
AIX : http://www-1.ibm.com/support/docview.wss?uid=swg2
Arizona functions well without DST because it's pretty far south, and the length of days doesn't change too much.
For those of us further north, DST is helpful, because having the sun rise at 4am and set at 8pm is wasteful, as most people don't start their days until much after 4, and their evenings certainly don't end at 8.
There was an interesting article in Slate a while ago arguing that it's not DST that should go, but time zones altogether.
Under Unix, you could configure time zone changes yourself with zic.
For example, the following input to zic will create the four zone info files US/Eastern, US/Central, US/Mountain and US/Pacific. These will be under your ZONEINFO directory (mine is /usr/share/zoneinfo).
The input above configures the time change for the years 2007 to 2017 (an arbitrary end year) so that DST starts the second Sunday in March, and ends the first Sunday in November, as specified in the Energy Policy Act of 2005.
You can test your resulting files using the zdump command, like this
You might have to refresh links to these new files, check /etc/localtime.
Disclaimer: I'm not a time zone expert, so don't take this on faith.