[tz] Today's CalConnect event

Steve Allen sla at ucolick.org
Tue Feb 5 19:52:02 UTC 2019

The speaker from Google Android team told some stories of time zone
disasters for people using their phones as reminders for time,
sketched past mechanisms (and lack thereof) for updating Android,
and hinted a new procedure being developed with vendors.

If I understood who was asking questions then the meeting today also
revealed that the yum updates from RedHat use IANA tz, but only the
rearguard form of data, and not the current code.

On Tue 2019-02-05T16:55:12+0000 Paul.Koning at dell.com hath writ:
> ISO is [...] an international version of standards bodies like ANSI, or like IETF.

ISO, who created the standard for the Open Systems Interconnection
(OSI) network model, a lesson that nobody should be allowed to forget.

There are also bureaus within IATA and ITU-R which have responsibility
for gathering and publishing timezone information.  Being also
international regulatory bodies they believe in working with ISO.

> It's not clear why ISO would be any more successful at cajoling
> country governments into early notice than the existing structure.

Possibly by fiat of membership in other international bodies.  Those
could make resolutions and/or recommendations that the participating
nations should follow an ISO procedure as one of the responsibilities
of membership.  This, of course, will lead to tensions as ISO has to
enumerate/id every zone including both "government approved" zones and
"in actual use" zones.  Given the history of international bodies
constructed for similar purposes it remains unclear how the operation
of this scheme would be funded and managed.

As seen in the discussions at the CalConnect meeting today (and also
in many newcomer postings to tz) most concepts of "what is a timezone"
have an entirely different basis than tz.  The existing implementation
of tzcode provides a lot more basis in real-world experience than is
found in a lot of standards and regulations.

Keeping OSI in mind, it is important that any standard not fall into
the trap of being too simple.  It is unfortunate that common beliefs
about time zones have a much simpler model than the real world, but
paying "blame the victim" is not a good strategy.  A better strategy
is to keep improving the documentation for tz and point to its
examples of "lessons learned" and "failed ideas".

The model for tz has a good start because it wants to solve the
problems of POSIX systems.  The code for tz has that model as its
basis.  The data for tz fit into that model but can be used elsewhere.
The docs for tz have a good start in that they explain the problems
that are and are not trying to be solved.  Answering the questions of
what problems are trying to be solved (and not) is a key basis for any

Also evident at the CalConnect meeting was the lack of awareness of
the many different mechanisms for distributing time zone info.
Microsoft Windows update
zones built into databases, internet of things, etc.

IANA tz is open, transparent, well-documented, and more mature than
any of the others.  The existence, goals, and reasons for existence of
all the other mechanisms are not like IANA tz.  These other mechanisms
do not describe how they use and filter IANA tz to remove information
deemed politically or diplomatically inadmissable by their products
when being used in particular jurisdictions.

I wish there were a writeup with detailed and brutally honest compare
and contrast of everything known about all methods of time zone
distribution.  The meeting today made the need for that quite evident.

Steve Allen                    <sla at ucolick.org>              WGS-84 (GPS)
UCO/Lick Observatory--ISB 260  Natural Sciences II, Room 165  Lat  +36.99855
1156 High Street               Voice: +1 831 459 3046         Lng -122.06015
Santa Cruz, CA 95064           https://www.ucolick.org/~sla/  Hgt +250 m

More information about the tz mailing list