[timezonediscuss-l] Summary of the EU time zone workshop - Zurich Feb 5th 2019 (repost)
mikeadouglass at gmail.com
Tue Feb 26 09:00:17 PST 2019
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
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
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
* 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
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
(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
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
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
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.
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
* Microsoft have their own separate database
* IATA have a database which is government provided and verified and
used by airlines
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
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.
More information about the timezonediscuss-l