So it would appear that the meddling fools in Washington have got it into their heads that we could save energy by extending Daylight Savings Time.  I’m not going to get into the issue of whether DST even makes sense anymore (with the mind-and-body-jarring loss of sleep associated with “spring forward”). 

The last time some political pointy-head monkeyed with DST was in 1974, during the Arab oil embargo.  The current boundaries of DST were set by Congress in 1986, which was a time when most computer systems were still adjusted manually for DST by operators. 

Since then, some systems (such as Unix) accounted for DST automatically by using rules based on the legal definitions of DST in the system’s (or user’s) locale.  For example, the POSIX standard defines a TZ variable format that allows for the specification of the starting and ending dates and times of DST in a particular timezone (as well as the offset). This can be a bit complicated, as we can see by looking at the example of the full definition for the Pacific timezone in the United States, which is “PST8PDT,M4.1.0/2,M10.5.0/2”.  That translates to a timezone known as PST that has an offset of 8 hours from UTC and is known as “PDT” during DST.  The “M” string means that DST starts on the 0th day (Sunday) of the first week (1) of April (4th month) at 2:00am (/2) and ends on the 0th day of the 5th week of the 10th month at 2:00am.  These POSIX strings are pretty messy, but they do allow for full flexibility in determining the current time in the given timezone. 

However, over the years these things have changed in certain areas, so if one is calculating the time in the past it isn’t sufficient to know the current politically-defined time.  Later versions of Unix (and variants like Linux) allow for location timezone settings using strings such as “America/Denver” or “:US/Pacific.”  This references a database that includes historical information in addition to the current political definition of the timezone.

So, given the above, one could conclude that it’s simply a matter of configuration to fix this sort of thing: simply download the new location database or fix the environment variables to include the new start/end dates.  However, things aren’t always this simple.  Consider that on some older systems this could affect time-of-day calculations when working with dates in the past, so you can’t just willy-nilly change these to the current values (Why would you worry about time-of-day in the past?  I could imagine that astronomy applications might have a need for accurate time when calculating things in the past…).

Windows would have a similar problem, in that it automatically adjusts for DST based on the timezone that is chosen at installation.  All Windows systems would require a code update to accomodate the changes to DST start and end.

While Unix and Windows at least have configuration settings, I wouldn’t doubt that there are many systems out there that don’t have any type of configuration.  These systems would either have to be patched or replaced.  Even on the systems where it’s just a configuration setting the issue of the volume of systems is daunting, in that there are millions of them.  If we wanted to ensure an absolutely smooth transition, it would require an effort in the IT industry similar to what we saw for Y2K.  The Y2K effort was estimated at costing $100-billion.

Perhaps this effort would be smaller, but it remains non-trivial.  Many programs would have to be examined to look for timezone-dependent code and to inspect that code to make sure it didn’t have any hard-coded behaviors.  At a minimum, every system would need to be tested, which costs time and money and could tie up the developers and the test environments for those systems, impacting other more productive work.

Update:  More thoughts here.