Question for the IT types reading here: What have you/your department/your company done to prepare for the upcoming changes to the start/end dates for Daylight Savings Time in Canada and the US?
I’m really surprised at how little mainstream or IT press the change has been getting so I’m wondering how ready other IT departments are for the change.
(Background: The US Energy Policy Act of 2005 changes the start date of DST from the first Sunday in April to the second Sunday in March, and the end date from the last sunday in October to the first sunday in November, so any software that deals with timezones needs to be updated to account for the change. Most Canadian provinces are implementing the same change.)
13 responses to “What’s your company doing about Daylight Savings Time?”
We plan on doing nothing.
Fortunately, the hardware we design only keeps track of GMT because that is what syslog and NTP uses, and everything else we need to do time-wise is simply deltas (“lock this connection for 10 minutes” and the like.) This was an intentional decision to ignore local time.
As far as the IT infrastructure itself, I have no clue. The company uses Windows boxes in general, but our department uses exclusively Linux boxes and just talks SMB and IMAP to the rest of the company. I think I recall hearing that Linux handles it fine (we’re using Fedora Core and regularly update with Yum), and even if it doesn’t… well, they are just development workstations. I think I also recall some question as to whether Windows supports the changed date…? I don’t know whether or not that has been resolved yet with a patch.
My main concern, actually, is in what would traditionally be thought of as a “non critical” system/device. My clock radio automatically adjusts itself for daylight savings. I don’t actually recall if this is because of the NOAA time broadcast over the radio or if it is hard-coded dates in firmware. The former should be fine, but the latter means I have to set it four times a year–twice to manually adjust it for daylight savings and twice to undo the adjustment it will try to make on the wrong date. I may be in the market for a new clock radio.
Nothing, AFAIK.
But then, like a surprisingly high proportion of the world’s population, we’re not in North America.
Not much, really. The one thing we’ve had to do is base all our new and maintenance releases that depend on Red Hat Enterprise Linux 4 to Update 4, which has the new DST support.
Actually, Juniper published a number of technical bulletins on the subject (proactive notices emailed to subscribed customers) for a variety of our products, detailing how the software would deal with the change. I hadn’t even thought about it until I worked on those bulletins, but I was impressed that they were handling this issue already…
Having a bit of a fit about it, I’m afraid. :)
That’s the page that got me thinking about it!
Glad to be of service. :D
This has been kind of a nightmare for us, thanks government! We have a whole slew of patches that have had to be applied and tested to all kinds of middleware in various environments (starting in development and going allllllll the way up to production.) We’re not quite done with that last bit yet, and each time we do a patchset we find some new thing that breaks – not really ever because of the new rules, but just as a side hazard of doing sweeping updates.
I don’t actually think we’ve bothered to test the time change itself at all yet.
Anyway, yeah.
I’m thinking it’s really unlikely that most IT departments are going to be ready.
For example, some versions of Lotus Notes/Domino have three different sources of time zone information: (1) the OS time zone settings, (2) an internal table of time zones, and (3) a third table of time zones embedded in the Java runtime which is embedded inside Notes/Domino. There are probably a lot of companies who aren’t going to be willing to deploy Notes 7.0.2 just to get the fixes, in which case they’re going to need to apply patches in all 3 locations and check configurations manually. And there’s no way to reconfigure Notes 6 on the Mac to get the new DST right…
Every time we go through this crap I move closer to just setting all my clocks and watches to UTC and saying I’m done with this time zone nonsense.
Probably goes without saying (and Brianenigma already hinted at it), but what we’re doing is “yum update tzdata”. That being said:
It’s worth reading the entire changelog, or at least skimming it, just to get a sense of how very common this sort of change is.
for my company, i just plan on rebooting all of our servers, thereby syncing them to time.nist.gov, and having the workstations just run a net time \\servername /set /yes to get them switched over.
as far as our calendaring goes, meetingmaker has a patch out to fix the governmental calendar game.
Feh, teh Linux servers all need a yum update tzdata. THAT took 10 seconds out of life per server. FC4 is at tzdata-2005i-2
Solaris OTOH requires patching not only the Solris tzdata equivalent but libc.so as well. Bah.