The times they are a-changing...
The last time the rules for entering and leaving Daylight Saving Time changed in North America was 1987. That was a very different world than we have today. It was significantly less automated, significantly less computerized and significantly less dependent on computers and software for accomplishing mission critical tasks.
So, on an upcoming fateful day in March 2007, when legal, civil time in North America's "Eastern Time Zone" jumps in an instant from 2007-03-11T01:59:59.99999999...-05:00 to 2007-03-11T03:00:00-04:00, what will happen? How many computer systems, and devices using embedded computer systems, will fail to recognize that civil time is suddenly an hour later than it had been? And what consequences are likely to ensue?
I strongly suspect (to put it mildly) that the number of systems that won't have the correct civil time will be decidedly non-trivial. But the likely consequences of that timekeeping failure are much harder to guess. One likely result will be users complaining about 1-hour time-of-day discrepancies. The most likely cause of serious malfunctions will be situations where two or more computer systems colloborate together in such a way that clock synchronization matters, with some (but not all) of them still using the old time zone rules for North America.
The best way to handle the problems that might arise due to your computers using the wrong time zone rules is to make sure all your computers know the new rules. If you do nothing, it's highly likely that your computers won't know anything about it (and that's true from Mainframes to PDAs, especially including computers that use Unix or Windows.)
Here are some resources with helpful information about updating the time zone rules for computers of various types:
- Are You Prepared for Daylight Saving Time 2007?
- Daylight Saving Time - The Year 2007 Problem
- Preparing Your Datacenters for DST Changes?
- 2007 time zone update for Microsoft Windows operating systems
But updating the operating system may not be sufficient. For reasons I won't go into here, there are many applications that don't rely on the OS to tell them what the time zone rules happen to be. One prominent example is Java. Another that may be of some interest to my intended audience on this blog (the community of Smalltalk programmers,) would be one of the most widely used Smalltalk variants: VisualWorks.
For information about updating Java applications with the new time zone rules, refer to the following:
Smalltalkers who use the Chronos Date/Time Library in their Smalltalk applications, and who obtained any version of the Chronos Time Zone Repository after late-August 2005 (a year and half ago!) already have the new time zone rules for North America. This is because the new rules were known as soon as Congress passed the Energy Policy Act of 2005 (in the Summer of 2005,) and also because the Chronos time zone rule sets are able to represent not only the rules for the current year, but also rules for other either past or future years that differ from those currently in effect.
As for those Smalltalkers who don't use Chronos in their applications, the situation is as follows:
VisualWorks: The time zone rules must be updated. My earlier blog post, VW: 2007 TimeZone settings for North America, explains how to do so.
Squeak: Those using the "out-of-the-box" Chronology classes don't need to do anything. But that's not because the Chronology classes know all about time zones, but rather because they don't. For many situations, there is no need for the Chronology classes to know anything about time zones. Squeak relies on the operating system to tell it what the local time currently is. That's a very simple approach...which stops working as soon as you need to do any of the following things:
- Convert a date/time from some other time zone into your local time (because you don't know what your offset from Universal Time happens to be, and may also not know the offset of the other time zone.)
- Convert a local date/time to some other time zone (for the same reasons as above.)
- Correctly compute the amount of physical, elapsed time between two points in time (because you won't know whether the time zone offsets of the two points in time were the same, since there may have been one or more intervening DST transitions; or worse, the two points in time may not even have been intended to represent time in the same time zone.)
- Correctly compute the point in time that results when adding a duration to a point in time (again, because you won't know whether the offset will be the same, since the offset may be different even a fraction of a second earlier or later.)
But those using Squeak have two other options. One is Chronos, which has already been discussed. The other is the David T. Lewis' TimeZoneDatabase (which functions in a way very similar to Chronos, at least as far as time zones are concerned.) Just like Chronos, the TimeZoneDatabase relies on an external repository of time zone rules--and both use the Olson Time Zone Database as the source of those rules. On Unix-based hosts, the TimeZoneDatabase can be configured to use the same binary "tzfiles" as Unix itself uses, at the same disk location--which means that updating the operating system's time zone rules also updates the TimeZoneDatabase. But on non-Unix based systems, the "tzfiles" must be updated separately.
Dolphin Smalltalk: Dolphin uses Windows system calls to get the current local time. Although Dolphin very helpfully provides the ability to get time zone information from the Windows Registry, its native TimeStamp class doesn't use that capability to provide time-zone-aware date/time behavior. Chronos is also available for Dolphin.
Most other Smalltalk systems are essentially similar to either Squeak or Dolphin, as far as time zone functionality is concerned.
But all this raises a very good question: Why are time zones such a hard problem?
No comments:
Post a Comment