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?"

Are you saying..

[by Anonymous Coward]

..that your servers don't use GMT?

What are you doing in your datacenters to prepare?

[by Anonymous Coward]

Using UTC.

Re:What are you doing in your datacenters to prepa

[by Anonymous Coward]

Mod parent up. ISTM that you're better off if all computers have their hardware clocks set to UTC and the conversions to local time take place at the last possible time in the clients (if at all). If a user wants to use some client software or OS that doesn't understand the silly daylight savings rules (which are extremely crazy in some places); at least they don't damage anything in the datacenter and will only confuse themselves.

OTOH, what kind of evil company won't even give as trivial a patch as updating a time-zone file to their customers!?! If I had any such software and the company still existed I'd be wanting a full refund.

You also have to look for what you applications do

[LordKronos (470910)]

Thats a good idea, but won't always solve all of your problems. Here's a problem I experienced recently with one of our web apps.

We have a web event calendar where people can schedule events (for far into the future). When people input an event, they specify the date/time it will begin/end. The application then converts the date/time into a unix timestamp and stores it in the database. Later, when an event is being viewed, the timestamp is converted back to a textual date/time.

The conversion from local time to timestamp is done via PHP functions, which uses the systems timezone file. The OS patch to fix this problem simply updates the timezone file and everything should automatically work.

This is fine and dandy for most things, but I ran into one small glitch. For any events that are scheduled between the new start of DST and the old start of DST (roughly a 3 week period), if they were created BEFORE the patch was applied, they are now off by 1 hour AFTER the patch is applied.

The 1 hour difference is simple enough, and I might not have even noticed...or if I had, I probably would have just blamed it on user error when entering the data. However, this caused a strange side effect. The application built a secondary index to simplify searching for events. The index consisted of the event_id and the starting timestamp truncated to midnight. Of course, for those events in that 3 week period that were created before the patch was applied, they now had an index timestamp that was actually 1 AM. Of course, this caused events to mysteriously disappear from the calendar. You could search for them, but not see them when browsing.

I wasted a good couple of hours on this problem (thinking at first that it was isolated to a single event) before I finally did an analysis of the entire index and discovered that almost all events in that 3 week period were wrong. Then it instantly dawned on me what had happened.

Europe

[AnriL (657435)]

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?

Not this year

[Silver Sloth (770927)]

But it's generally true that what the US does today we Europeans will do next year. Furthermore, if it's found that the change in Daylight Savings does have energy use benefits, then I can see that the benefits outweigh any drawbacks.
The good thing is that when we get around to doing it our US colleages will have found all the problems!

Avoid the problem in the US

[ziegast (168305)]

In the US, move your servers to Arizona or eastern Indiana or Hawaii or Alaska, so you don't have to deal with time zone changes anymore.

-ez

Re:

[_mythdraug_ (27158)]

All of Indiana will honor DST this year. (Yet another change to have to be prepared for)

Re:

[billdar (595311)]

most people don't start their days until much after 4, and their evenings certainly don't end at 8.

Obviously you're not a parent...

I'm more concerned of a switch back to the old....

[Antony-Kyre (807195)]

I'm more concerning of a switch back to the old DST (the one we had in 2006) if they decide it's the energy saving isn't good enough. How difficult would it be to unpatch out systems?

Servers should be on UTC anyway

[by Anonymous Coward]

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.

Re:

[ozbon (99708)]

Exactly what I was going to say.

Even on the web-apps I write, I always convert to GMT (or UTC, whichever terminology you care to use) rather than shafting about with time-changes, time-zone issues, and all that cack.

Mind you, I also rarely (if ever) use the timestamps as an identifier either, for similar reasons.

I suspect that if a server/db is using timestamps (including microtime, or whatever) as a unique identifier, then that's a whole new world of hurt.

Re:People should be on UTC anyway

[anon mouse-cow-aard (443646)]

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 tim

Dammit

[Timesprout (579035)]

I just got my servers switched over from the Julien to the Gregorian calender. Now this. When will it ever end.

Re:

[Cyberax (705495)]

You think it's funny...

I have helped to maintain some computers in my local Orthodox Christian church. Orthodox Church _still_ uses Julian calendar (that's why Orthodox Christmas is celebrated on Jan 7), so I had to install patches that add Orthodox calendar support to Windows. It was not funny.

Re:

[MobileTatsu-NJG (946591)]

"I just got my servers switched over from the Julien to the Gregorian calender. Now this. When will it ever end."

You think that was bad? You should have been around for the BC to AD conversion. Yikes.

BC to AD

[camperdave (969942)]

You should have been around for the BC to AD conversion.

We thought we were going to be fine with that here, as we had some wise men who worked out when they were going to start. We were planning on just using an integer for number of years:positive for AD, negative for BC. However, some idiot politician somewhere decided to start labelling the years at 1 instead of 0, so now we've got an out-by-one bug every time you try to do a calculation that crosses the AD/BC boundary.

Where to get time zone info source files from

[by Anonymous Coward]

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/ [nih.gov], 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.

Re:

[tricorn (199664)]

This also applies to all Mac OS X machines as well, of course. Apple will supply a new set of timezone files in a patch (if they haven't already), and there's absolutely no reason it won't be available for every version of OS X (since they should be the exact same files, the format hasn't changed). Doesn't Windows use a similar method? I thought pretty much everything had switched over to zic-based timezone files (which also takes care of all those pesky leap-seconds that everyone seemed to be so worried

Not quite true...

[oDDmON oUT (231200)]

"...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.

Patch to change DST?

[Sique (173459)]

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 [microsoft.com], 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 [microsoft.com].

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.

Java...

[loony (37622)]

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.

We should ban the numbers 13 and 911 too...

[anon mouse-cow-aard (443646)]

Out of deference to the events in 2001, the number 911 should be reserved for unique use (in North America) of the emergency services telephone number, it's use in all other contexts... 13 could be included in the ban to standardize current practices. Most high rises do not have a thirteenth floor, and Friday the 13th would cease to be a problem. No price, by law, for any item will ever be 13 or 911 dollars, except on march 13th (except when that would fall on a friday, in which case it would be a slip year), and September 11th, when those prices will be allowed. No use of the numbers 13 or 911 will be permitted in architectural or engineering diagrams of any kind, for fear offending those who lost loved ones on that terrible day.

The impact on counting should be very minor, as I personally lived in an apartment on 12B for many years, and there was no cost to this. A few if statements here and there. Sure, there are some complications,
Look, for example at the daylight savings time, how simple it is to understand that on some days of the year, there are 23 hours, (where there is no 3:12 am.) and on others, there are 25 hours (where there are two 3:12 am's.) but only in some places, sometimes, depending on what the local government says.

It is great to change how people count... dollars, dimensions, hours, to serve political or societal goals. It makes life better for everyone. Much simpler than changing prices or opening hours to serve them. All we need to do is pass a law, and change the way we count. Simple and practical so that no one has to keep track.

DIY Time Zone configuration

[jrifkin (100192)]

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).

# Rule NAME FROM TO TYPE IN ON AT SAVE LETTER/S
Rule DST 2007 2017 - Mar Sun>=8 2:00 1:00 D
Rule DST 2007 2017 - Nov Sun<=7 2:00 0 S

#Zone NAME GMTOFF RULES/SAVE FORMAT [UNTIL]
Zone US/Eastern -5:00 DST E%sT
Zone US/Central -6:00 DST C%sT
Zone US/Mountain -7:00 DST M%sT
Zone US/Pacific -8:00 DST P%sT

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 [wikipedia.org].

You can test your resulting files using the zdump command, like this

> zdump US/Eastern
> zdump -v US/Eastern

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.

Re:

[Cheeze (12756)]

I don't think you work in a datacenter then. Once our servers are configured and running, there should NEVER be a reason to reboot them. In fact, when we have an odd server failure, the server usually has been up since it was first put in the datacenter. We are just now getting failures of systems put up in the late 1990s. Sure we have new systems as well, but there are critical systems still running old hardware because it works and a reboot is too much of an outage to take.

If you don't think it could be i