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@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 standard. Also evident at the CalConnect meeting was the lack of awareness of the many different mechanisms for distributing time zone info. Microsoft Windows update Java Android CLDR ICU 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@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