[timezonediscuss-l] Summary of the EU time zone workshop - Zurich Feb 5th 2019

[Michael Douglass]

This document represents a first, public summary of the “EU time zone workshop” at CalConnect XLIV in Zurich on February 5th 2019, hosted by Google in Zurich.

The workshop was initiated by CalConnect after the EU’s recent proposed changes to DST rules. Shortly after the EU’s proposal, CalConnect had issued a public note, stating that a too fast implementation of suggested changes might yield several problems for IT systems, given the current state of practice about how time zone updates are handled in technical systems.

Given the impact of EU-wide changes and given prior occasions such as the US EDST debate 2005-2008, during which CalConnect conducted extensive work, CalConnect decided to hold a public workshop in order to allow practitioners from both governments and tech to discuss future improvements on how to handle the process of time zone changes.

Even though the EU in the meantime had relaxed their schedule on changing DST rules, CalConnect wants to continue discussions on time zone changes, since it is a frequent concern also beyond the particular EU case.

36 people attended the workshop onsite and up to 9 people joined the live video-stream. Participants represented a number of major vendors and the IANA tz database. Unfortunately, there was no major participation from the governance side (i.e., people involved in political decisions about time zone changes), so that the workshop mainly involved technical discussions.

The workshop opened with a summary of the EU proposed changes to DST. This was followed by a presentation outlining the history of work by CalConnect on time zones.

Current problems in dealing with time zone changes can roughly be categorized as:
   * Governance: how to (timely) communicate time zone changes to the maintainers of time zone database such as the IANA tzdb
   * Distribution: how to push updates of timezone databases (such as IANA tzdb) to the devices and systems using these databases
   * Application: How to educate developers and administrators about dealing with time zones

Governance

Currently, there is no structured way how government decisions about time zone changes are propagated to the maintainers of timezone databases.

There are indications of communication channels from governments to the maintainers of the IATA SSIM manual. Updates to the IANA tzdb are typically directed to their mailing list, sometimes referencing legal documents, sometimes referencing newspaper reports. For some notable timezone databases, such as the one maintained by Microsoft, details about this process are unknown.

Also, best practices for governments on when to communicate time zone changes only exist in an informal or semi-formal manner (such as IANA tzdb and Microsoft’s recommendation of at least one year lead time).

As the workshop did not involve participants from government, governance topics were not discussed in depth.

However, there is an upcoming effort within ISO about defining a standard and registry for for advance notification of time zone changes in a more structured way, in which CalConnect is involved as an ISO liaison. There was some hope in the workshop and later on the IANA tzdb mailing list (https://mm.icann.org/pipermail/tz/2019-February/027503.html), that such a standard could help encourage compliance by countries to follow a more structured procedure given ISO's governmental connections.

However, this ISO discussion is currently still in a very early stage and it might take some few years until a described framework will be in place.

Distribution

The common form of distribution for time zone information and its updates nowadays seems to the physical distribution of timezone databases (and updates to those) to devices and systems. In many cases, the updates also require a reboot of the underlying machine in order to become effective.

There was a presentation on the approach taken by Google to update Android devices. A Google representative mentioned communication efforts by Google in a recent case, where a short term governmental time zone change could not be propagated quickly enough to devices, so that users were at risk of missing an important nationwide exam. Google is thus striving to speed up the process of rolling out time zone updates. The representative noted the company's "under construction" (no details provided) effort to develop a time zone information distribution mechanism that would allow data to get from IANA publication to in-the-field Android devices within a month (seen as a reasonable objective that would deal with most real-world situations).

Some comments made during the presentations and in the following discussions suggested that a significant factor in the delays is the desire by vendors to validate and test the results of time zone changes. This can lead to a delay of many weeks.

It was also pointed out that one computer might use several time zone databases at a time - e.g., for the core operating system, a runtime environment, and a database system.
So even if vendors are optimizing this process and trying to avoid the necessity for reboots, there is still significant time required to update devices with correct time zone information.

The longer a client or service has incorrect timezone data the more user data may be made incorrect so it was felt a timely delivery service would help to mitigate any delays.

These issues led to the development of TzDist - The Time Zone Data Distribution Service (RFC 7808) which is intended to allow the timely delivery of time zone information. The specification assumes that such a service will be a hierarchy of TzDist servers all fed by the root. It is also assumed vendors would run their own downstream servers for their systems.

There was a suggestion at some point that somebody should update a linux distribution to make use of a TzDist server. This would use the data format defined in RFC 8536 The Time Zone Information Format (TZif) which provides a formal definition of the data format used by most UNIX systems.

Additionally, it was pointed out that to correct data when rules change requires that at least the local time, timezone id and UTC time be recorded. And once again it was pointed out that to the end user the important element is the local time.

General discussion

Following these presentations there was a chance for open discussion on the issues and on other approaches.

There was some discussion of hoped for work on the time zone database, both changes (to opaque time zone identifiers) and additions (of localization information, zone boundary information, and sequencing information to track splits and mergers of time zones). There is recognition that the work is a volunteer effort and that there's a limit to what volunteers can do.

Generally, people value in having open database maintenance processes (such as the one now used by IANA). Having multiple sources of time zone information would allow them to be cross-checked against one another. Already existing databases are:
   * IANA who have taken over the Olsen zones and keep them updated (see RFC 6557)
   * Microsoft have their own separate database
   * IATA have a database which is government provided and verified and used by airlines

Intermediate summary

As expected, the workshop did not yield any final conclusions, but has shown that the current state of propagating time zone changes to systems and devices may easily yield issues, even though it is generally working.

To this extent, this workshop summary is also intended as a starting point for further discussion, either on mailing lists (such as https://www.calconnect.org/resources/discussion-lists/time-zone-discussion) or during potential future workshops - also in order to promote particular initiatives such as the ISO time zone changes registry and the TzDist approach.

In particular, CalConnect’s technical committee for date and time zone topics (TC DATETIME) will continue to follow up with this and determine next steps and future steps for CalConnect.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.calconnect.org/pipermail/timezonediscuss-l-calconnect.org/attachments/20190226/202de552/attachment.html>