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

[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.