Not too many people are paying attention, but the Energy Policy Act of 2005 lengthened daylight saving time by four weeks in the US. Instead of beginning the first Sunday of April and running through the last Sunday in October, daylight saving time will now stretch from the second Sunday in March to the first Sunday in November. The Washington Post has an article today about the change and what impact it might have on automated systems:
The change takes effect this year -- on March 11 -- and it has angered airlines, delighted candy makers and sent thousands of technicians scrambling to make sure countless automated systems switch their clocks at the right moment. Unless changed by one method or another, many systems will remain programmed to read the calendar and start daylight saving time on its old date in April, not its new one in March.
The article mentions that older Microsoft products like Windows XP SP1 and Windows NT4 might require manual updates and Daring Fireball has had a few updates about how the switch effects Mac users, including this piece at TidBITS. But what about everything else? Is the version of Movable Type I'm using going to make the adjustment? What about Wordpress? Perl? Ruby? PHP? Java? Linux? I'm sure the current versions of all these programs and languages address the issue, but are there fixes and patches for those running old versions of Perl on their server?
If you've got any information about programs, applications, and languages affected by the change and how to address the problem, leave a comment on this thread. I'll update the post as information comes in.
Reader Comments
26 comments
My employer is in the video server business, and we had to come up with a fix.
For the Solaris machines we use, there was a fairly simple patch. As I understand it, an update to a few directories full of time zone definition files.
Our proprietary machines use a Plan 9 derived OS. The time zone / DST functionality was not standardized. The fix consisted of porting over the standard UNIX way of doing things.
Coincidentally, I helped a customer update a machine last night so they could do some advance testing. I logged in to check, and the transition occurred OK.
For the Solaris machines we use, there was a fairly simple patch. As I understand it, an update to a few directories full of time zone definition files.
Our proprietary machines use a Plan 9 derived OS. The time zone / DST functionality was not standardized. The fix consisted of porting over the standard UNIX way of doing things.
Coincidentally, I helped a customer update a machine last night so they could do some advance testing. I logged in to check, and the transition occurred OK.
For the most part, date and time isn't handled on a language-by-language basis like that- your MT installation relies on your site's server for it's date and time. So as long as the machine it's on is set correctly, MT, Ruby, PHP etc will all have no problem with it.
It's an issue that needs to be addressed closer to operating system level than application. I think!
It's an issue that needs to be addressed closer to operating system level than application. I think!
On the Mac, you need to be on 10.4.6+
I have multiple devices in my house (cameras, camcorders, security system, eletronic clocks in several appliances) which implement daylight savings time "the old way".
To me, making this change is a huge disruption. I would like to see evidence that this change results in substantial savings.
Arizona and Hawaii once again wisely opted out from this scheme, but Canada, strangely, complied. Perhaps it's time to annex them, after all.
To me, making this change is a huge disruption. I would like to see evidence that this change results in substantial savings.
Arizona and Hawaii once again wisely opted out from this scheme, but Canada, strangely, complied. Perhaps it's time to annex them, after all.
it's like y2k all over again- planes will fall from the sky! the power grid will collapse! start stocking your daylight savings bunkers now!!!
the only thing I can think of... besides the mess that this may (or may not cause) is that:
Again, the U.S. will be different from everyone else in the World... not only we'll have different measurement units, but now we'll have different standards on when to go DST.
Why don't we make our 24-hour days be 25-hours in the process.
=(
Again, the U.S. will be different from everyone else in the World... not only we'll have different measurement units, but now we'll have different standards on when to go DST.
Why don't we make our 24-hour days be 25-hours in the process.
=(
There are basically three classes of thingy that need updating: operating systems' timezone data, Java VMs' timezone data, and braindead applications that thought hardcoding timezones was a good idea.
The latter category probably applies primarily to older enterprise applications, and to little mickey-mouse one-off programs. Anything that is Java-based should be taken care of with the appropriate Java update, and anything that isn't should be taken care of with the appropriate OS update (if available).
The latter category probably applies primarily to older enterprise applications, and to little mickey-mouse one-off programs. Anything that is Java-based should be taken care of with the appropriate Java update, and anything that isn't should be taken care of with the appropriate OS update (if available).
NT 5+ can be fixed from the registry with a .reg file. I just got through creating a patch to send out to our customers who we still support on older windows system.
On something unix-y PHP uses the underlying system's date functions and will just work if the system's /etc/localtime file (or equivalent) has been updated to reflect the new DST rules; I don't know about running PHP on Windows. I'd imagine that PHP applications (like Wordpress) will use the build-in PHP functions for date calculations and hopefully haven't re-invented that particular wheel.
We've been saving daylight for years, but we haven't done anything with it. I say we take this daylight surplus out of its lockbox and give it back to the American people. It's our daylight, not the government's.
I wonder if the energy savings the four weeks of extra daylight savings will give us will be offset by the loss of productivity of people futzing with clocks and old computers... it will be years before all the old technology is updated with new rules.
As an aside, I swear I never quite adjust to daylight savings, and am always glad to be back in standard time.
As an aside, I swear I never quite adjust to daylight savings, and am always glad to be back in standard time.
I love daylight savings time. It means I can get out from work and still hit the trails on my Mt. bike.
This is really a complete non-issue. Any OS under support has already had its timezone files updated, and that should affect all reasonable apps underneath it (as rich notes, there may be some that break, but they're broken anyway).
Any electronics or device that implements DST tracking and does so from its own internal database was already broken -- as noted, not all states participate in DST. In Illinois it's on a county-by-county basis.
And the US is hardly the only country that has DST, or the only country that changes DST. Brazil changes when it starts and stops yearly, since the legislature has to vote on it. Some years they don't even have DST. And yet, somehow, their IT infrastructure survives.
Any electronics or device that implements DST tracking and does so from its own internal database was already broken -- as noted, not all states participate in DST. In Illinois it's on a county-by-county basis.
And the US is hardly the only country that has DST, or the only country that changes DST. Brazil changes when it starts and stops yearly, since the legislature has to vote on it. Some years they don't even have DST. And yet, somehow, their IT infrastructure survives.
I was looking into this yesterday and discovered one of the unknowns was what do you do with applications or events which have be scheduled in what was supposed to be standard time but is now daylight savings time. Some timezone aware applications will use GMT for the internal date and will happily change the time for your 1:00 p.m. EST meeting to 2:00 p.m. EDT. Others will store the time as an internal local time, ignoring the timezone.
If you are curious if your linux/unix server will make the switch correctly try:
date --date="Mar 25 15:00:00 UTC 2006"
Sat Mar 25 10:00:00 EST 2006
and then
date --date="Mar 25 15:00:00 UTC 2007"
Sun Mar 25 11:00:00 EDT 2007
As you can see, the output differs for 2006 and 2007. That
indicates that [the system includes the] changes required by the
"Energy Policy Act of 2005," which mandates new dates for
transition between Standard Time and Daylight Saving Time
starting in 2007.
if the output is the same, you need to do the update.
via centos list archive
and another good thread about updating.
date --date="Mar 25 15:00:00 UTC 2006"
Sat Mar 25 10:00:00 EST 2006
and then
date --date="Mar 25 15:00:00 UTC 2007"
Sun Mar 25 11:00:00 EDT 2007
As you can see, the output differs for 2006 and 2007. That
indicates that [the system includes the] changes required by the
"Energy Policy Act of 2005," which mandates new dates for
transition between Standard Time and Daylight Saving Time
starting in 2007.
if the output is the same, you need to do the update.
via centos list archive
and another good thread about updating.
Jason, perhaps you might like to mention that this effects the US only in the text of your original article. Being British, when I first read it I got rather worried i'd not heard about this! It took reading the comments to clear it up.
There's an easier way to test the timezone files on Unix:
zdump -v TIMEZONE | grep 2007
That will show you the discontinuities in that timezone for 2007. (Try "America/Eastern" or "EST5EDT" for TIMEZONE.) Here's sample output on an unpatched server:
EST5EDT Sun Apr 1 06:59:59 2007 UTC = Sun Apr 1 01:59:59 2007 EST isdst=0
EST5EDT Sun Apr 1 07:00:00 2007 UTC = Sun Apr 1 03:00:00 2007 EDT isdst=1
EST5EDT Sun Oct 28 05:59:59 2007 UTC = Sun Oct 28 01:59:59 2007 EDT isdst=1
EST5EDT Sun Oct 28 06:00:00 2007 UTC = Sun Oct 28 01:00:00 2007 EST isdst=0
And here's sample output on a patched one:
EST5EDT Sun Mar 11 06:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 EST isdst=0 gmtoff=-18000
EST5EDT Sun Mar 11 07:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 EDT isdst=1 gmtoff=-14400
EST5EDT Sun Nov 4 05:59:59 2007 UTC = Sun Nov 4 01:59:59 2007 EDT isdst=1 gmtoff=-14400
EST5EDT Sun Nov 4 06:00:00 2007 UTC = Sun Nov 4 01:00:00 2007 EST isdst=0 gmtoff=-18000
zdump -v TIMEZONE | grep 2007
That will show you the discontinuities in that timezone for 2007. (Try "America/Eastern" or "EST5EDT" for TIMEZONE.) Here's sample output on an unpatched server:
EST5EDT Sun Apr 1 06:59:59 2007 UTC = Sun Apr 1 01:59:59 2007 EST isdst=0
EST5EDT Sun Apr 1 07:00:00 2007 UTC = Sun Apr 1 03:00:00 2007 EDT isdst=1
EST5EDT Sun Oct 28 05:59:59 2007 UTC = Sun Oct 28 01:59:59 2007 EDT isdst=1
EST5EDT Sun Oct 28 06:00:00 2007 UTC = Sun Oct 28 01:00:00 2007 EST isdst=0
And here's sample output on a patched one:
EST5EDT Sun Mar 11 06:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 EST isdst=0 gmtoff=-18000
EST5EDT Sun Mar 11 07:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 EDT isdst=1 gmtoff=-14400
EST5EDT Sun Nov 4 05:59:59 2007 UTC = Sun Nov 4 01:59:59 2007 EDT isdst=1 gmtoff=-14400
EST5EDT Sun Nov 4 06:00:00 2007 UTC = Sun Nov 4 01:00:00 2007 EST isdst=0 gmtoff=-18000
Paul B: It doesn't affect the US only. It also affects Canada and the Bahamas, and there's an unrelated DST change in Australia this year.
There is a generic test plan over at stickyminds.com.
Daylight Saving Time Strategy Test Plan.doc
Worthwhile reading.
http://www.stickyminds.com/s.asp?F=S11856_ART_2
Daylight Saving Time Strategy Test Plan.doc
Worthwhile reading.
http://www.stickyminds.com/s.asp?F=S11856_ART_2
Zathrus--this is certainly NOT a "non-issue." A lot of more complex applications that interact with other systems (as collab calendaring apps such as Outlook often do) have their own abstracted calendaring engine separate from the OS as they cannot always easily rely on the OS as a source for managing cross-platform/system calendaring. Further, many of these apps were first written well before robust (/mutable) timezone support was supported by many operating systems.
Speaking as a PHP developer, I have to agree with Andy: this is a significant issue... though not a new one.
Time zones have been a major PHP annoyance for a long time. If you just want to display and parse times and dates in the local server time, there's no problem. But applications like Textpattern, Wordpress and the like are designed to work on shared servers where the local server time probably doesn't match the user's time zone. In this type of situation, "leaving it to the OS" isn't an option.
Until PHP 5.1 there was no reliable, cross platform way to adjust a timestamp to a specific time zone. Applications had to implement ugly hacks to allow user-selectable time zones. Most of them use a simple offset that doesn't automatically adjust for DST. That's not going away anytime soon: the new TZ features in PHP 5.1 are still incomplete, and most shared hosting services are still running PHP 5.0 or 4.4.
The problem hasn't suddenly appeared with the US DST changes. Many countries have arcane and variable rules for when daylight saving begins and ends, or if it is observed at all. Often different states or provinces within a single Zone will have different rules.
Time zones have been a major PHP annoyance for a long time. If you just want to display and parse times and dates in the local server time, there's no problem. But applications like Textpattern, Wordpress and the like are designed to work on shared servers where the local server time probably doesn't match the user's time zone. In this type of situation, "leaving it to the OS" isn't an option.
Until PHP 5.1 there was no reliable, cross platform way to adjust a timestamp to a specific time zone. Applications had to implement ugly hacks to allow user-selectable time zones. Most of them use a simple offset that doesn't automatically adjust for DST. That's not going away anytime soon: the new TZ features in PHP 5.1 are still incomplete, and most shared hosting services are still running PHP 5.0 or 4.4.
The problem hasn't suddenly appeared with the US DST changes. Many countries have arcane and variable rules for when daylight saving begins and ends, or if it is observed at all. Often different states or provinces within a single Zone will have different rules.
I work for a major records storage/destruction company. This is going to screw the pooch for sure.
So the airlines are upset? Cry me a freaking river. You'll notice that it's the Energy Policy Act of 2005 - it's provisions were specifically delayed for a year at the request of entities like the airlines so that they'd have additional time to get ready. And now they're all acting like this has been suddenly thrust upon them...
well crew me a river and fry me a pooch, i've never even known which part of the year was savings time anyhow.
People: It's "Daylight Saving Time," not "Daylight Savings Time." There's a difference. See http://webexhibits.org/daylightsaving/b.html for an excellent explanation of Daylight Saving Time.
This thread is closed to new comments. Thanks to everyone who responded.
