How prepared is your organization for the Daylight Savings Time changes?
January 17, 2007 8:24 AM Subscribe
Mostly directed at IT types:
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.)
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.)
Um, nothing. Our server gets time from the Internet and the workstations sync their time to the server.
posted by jmd82 at 9:11 AM on January 17, 2007
posted by jmd82 at 9:11 AM on January 17, 2007
Response by poster: jmd82: That time from the Internet is UTC. Unless all the computers only ever display UTC, you're still using timezones.
posted by mendel at 9:25 AM on January 17, 2007
posted by mendel at 9:25 AM on January 17, 2007
Things that I know of: A full audit of all linux / solaris systems to ensure that appropriate patch leves were installed, a full audit of all java versions with several recommended upgrade paths, and roll-forward time testing on weekends to ensure that everything plays nice. Not sure about other platforms.
posted by true at 9:59 AM on January 17, 2007
posted by true at 9:59 AM on January 17, 2007
I'm stockpiling water and canned food in anticipation of worldwide failure of nearly all post-1900 technology.
more seriously, I assume that an update for my operating system will correct (or has already corrected) the DST rules, and I need take no particular action. Indeed, I just checked and I already have the new rules installed.
posted by jepler at 10:11 AM on January 17, 2007
more seriously, I assume that an update for my operating system will correct (or has already corrected) the DST rules, and I need take no particular action. Indeed, I just checked and I already have the new rules installed.
posted by jepler at 10:11 AM on January 17, 2007
mendel:
Dang, my diabolical plan is thwarted again. In the meantime, I'll just refrain from worrying about it and assume a Windows patch will deal with it.
posted by jmd82 at 10:21 AM on January 17, 2007
Dang, my diabolical plan is thwarted again. In the meantime, I'll just refrain from worrying about it and assume a Windows patch will deal with it.
posted by jmd82 at 10:21 AM on January 17, 2007
Interesting question. I have already patched my OS accordingly. But, I do have clients that are running various Linux flavors (RedHat & SuSE) and I'm wondering what they are planning to do.
I know it can have an effect: last November they did not account for the time change and a lengthy batch cycle ran into business hours which caused all sorts of havok with online systems.
posted by ca_little at 10:23 AM on January 17, 2007
I know it can have an effect: last November they did not account for the time change and a lengthy batch cycle ran into business hours which caused all sorts of havok with online systems.
posted by ca_little at 10:23 AM on January 17, 2007
We're a little worried. There are a bunch of legacy type systems around (mainframe specifically) and most of the staff were hired after 1987, so no one really remembers what was involved the last time DST changed.
In a lot of our Windows workstations, we removed the Automatically Adjust for DST option anyway (it was causing some issues with some of our disk protection software and kerberos ticket issuance) so I'm not that concerned provided the workstations can synch with the DC's.
We use WSUS so we'll deploy the patch to our non-protected workstations when it's available through the service (hopefully soon).
posted by purephase at 10:46 AM on January 17, 2007
In a lot of our Windows workstations, we removed the Automatically Adjust for DST option anyway (it was causing some issues with some of our disk protection software and kerberos ticket issuance) so I'm not that concerned provided the workstations can synch with the DC's.
We use WSUS so we'll deploy the patch to our non-protected workstations when it's available through the service (hopefully soon).
posted by purephase at 10:46 AM on January 17, 2007
Oh, and for the workstations that don't automatically adjust? I wrote some startup scripts that handle the active bias (so the workstations show the correct time).
posted by purephase at 10:47 AM on January 17, 2007
posted by purephase at 10:47 AM on January 17, 2007
I'm writing a sequel.
But seriously, I'm also surprised not to have heard more about this. DST is always a pain to deal with to begin with because of all the local variations worldwide. Although I have to say that thinking back over my years of coding, I've rarely if ever had to write code to figure out directly whether DST is in effect; it's almost always given by a system call or module. So it seems like this is more an issue of applying patches and updates than going in and fixing code.
Candy lobby 1, system administrators 0...
posted by staggernation at 10:48 AM on January 17, 2007
But seriously, I'm also surprised not to have heard more about this. DST is always a pain to deal with to begin with because of all the local variations worldwide. Although I have to say that thinking back over my years of coding, I've rarely if ever had to write code to figure out directly whether DST is in effect; it's almost always given by a system call or module. So it seems like this is more an issue of applying patches and updates than going in and fixing code.
Candy lobby 1, system administrators 0...
posted by staggernation at 10:48 AM on January 17, 2007
We've done a few things (Fortune 500 company, 200+ IS staff). First of all, we've set up an emailbox to serve as a collection point for information on affected applications and systems. We have a couple people monitoring it and organizing the contents on a portal.
We've got apps and systems to be addressed assigned to their logical parties. We've already sent the Windows Hotfix to our workstations. The Java Runtime Environment kind of scares us a bit (apparently, they all need patched separately).
At this point, it's just a matter of following up with the people assigned their responsibilities, implementing the fixes, and waiting for DST to begin to see what really breaks.
posted by bwilms at 12:20 PM on January 17, 2007
We've got apps and systems to be addressed assigned to their logical parties. We've already sent the Windows Hotfix to our workstations. The Java Runtime Environment kind of scares us a bit (apparently, they all need patched separately).
At this point, it's just a matter of following up with the people assigned their responsibilities, implementing the fixes, and waiting for DST to begin to see what really breaks.
posted by bwilms at 12:20 PM on January 17, 2007
Most OSs recent patches have already taken the timezone changes into account. AIX had a IY out almost a year ago (I believe it was contained in Maintenance Level 4 for 5.3). Most Linux distros had their timezone RPMs updated around a year ago as well, so if you have automatic updates turned on (or use SUMA on AIX), you should be fine as far the OS goes.
Java, on the other hand, requires manual update. And that is the real bitch; practically every goddamn enterprise app on earth uses java now. For IBM java, SR5 or above will contain the timezone fix; if you don't feel like updating the whole java, you can use their JTZU tool to update only the timezone info. If you're not an IBM shop... um, just get a recent java, it's probably been fixed in the last 6 months or so. I know that java 1.5 has the timezone change built-in from the start, without any fixes required. So maybe you should take this opportunity to jump to 1.5?
So to answer the question, we're about half prepared. All of the OSs are fine, but all of the javas are on the fast track to fucking the entire company to death. Despite the flippant comments above, I do believe the DST change will be bigger than Y2K in terms of actual effect on IT (not money spent, or time preparing though).
posted by synaesthetichaze at 4:09 PM on January 17, 2007
Java, on the other hand, requires manual update. And that is the real bitch; practically every goddamn enterprise app on earth uses java now. For IBM java, SR5 or above will contain the timezone fix; if you don't feel like updating the whole java, you can use their JTZU tool to update only the timezone info. If you're not an IBM shop... um, just get a recent java, it's probably been fixed in the last 6 months or so. I know that java 1.5 has the timezone change built-in from the start, without any fixes required. So maybe you should take this opportunity to jump to 1.5?
So to answer the question, we're about half prepared. All of the OSs are fine, but all of the javas are on the fast track to fucking the entire company to death. Despite the flippant comments above, I do believe the DST change will be bigger than Y2K in terms of actual effect on IT (not money spent, or time preparing though).
posted by synaesthetichaze at 4:09 PM on January 17, 2007
We patched everything. If anything breaks, chances are we simply won't give a shit.
posted by drstein at 9:21 PM on January 17, 2007
posted by drstein at 9:21 PM on January 17, 2007
This thread is closed to new comments.
Not a very good data point, I admit.
posted by nekton at 9:06 AM on January 17, 2007