Daylight saving started yesterday: the first time since 1991/1992 summer for Western Australia. The legislation finally passed the upper house on 21st November (12 days before the transition date). The updated tzdata packages were released on 27th November (6 days before the transition). So far, there hasn’t been an updated package released for Ubuntu (see bug 72125).
One thing brought up in the Launchpad bug was that not all applications used the system /usr/share/zoneinfo time zone database. So other places that might need updating include:
- Evolution has a database in /usr/share/evolution-data-server-$version/zoneinfo/ that is in iCalendar VTIMEZONE format.
- Java has a database in /usr/lib/jvm/java-$version/jre/lib/zi. This uses a different binary file format.
- pytz (used by Zope 3 and Launchpad among others) has a database consisting of generated Python source files for its database.
All the above rules time zone databases are based on the same source time zone information, but need to be updated individually and in different ways.
In a way, this is similar to the zlib security problems from a few years back: the same problem duplicated in many packages and needing to be fixed over and over again. Perhaps the solution is the same too: get rid of the duplication so that in future only one package needs updating.
As a start, I put together a patch to pytz so that it uses the same format binary time zone files as found in /usr/share/zoneinfo (bug 71227). This still means it has its own time zone database, but it goes a long way towards being able to share the system time zone database. It’d be nice if the other applications and libraries with their own databases could make similar changes.
For people using Windows, there is an update from Microsoft. Apparently you need to install one update now, and then a second update next year — I guess Windows doesn’t support multiple transition rules like Linux does. The page also lists a number of applications that will malfunction and not know about the daylight saving shift, so I guess that they have similar issues of some applications ignoring the system time zone database.
Another example of the same problem being “solved” over and over again is locales. I created a locale definition for en-US@ISO (ISO 8601), only to discover that it only works for command line programs–X software has its own locale system.
Just out of curiosity, why doesn’t Australia switch at the same time as most of the rest of the world? Most South American countries that observ it switch at the same time as Europe and Asia does. Our North American friends always has to be special of course, but that’s just business as usual.
Henri: Looking at the time zone definitions from the tzdata package, there is a huge variation in the start/end dates for different countries and the times of day they choose to have the transitions (and whether they define the transition times in terms of standard time or wall clock time). Some countries like Brazil don’t even have a predictable rule for determining the transition dates.
Europe seems to be a bit of an anomaly, with a bunch of countries agreeing on transition times (not that that’s a bad thing).