Today's CalConnect event
I listened in on today's just-concluded CalConnect event; CalConnect is "the calendaring and scheduling consortium." Just a few notes. I heard hopes 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 was recognition that the database work is a volunteer effort and that there's a limit to what volunteers can do. There was mention by an ISO person of ISO's effort to establish a time zone registry with requirements for advance notification of changes; the hope is that the ISO's governmental connections would help encourage compliance. A Google 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 devices within a month (seen as a reasonable objective that would deal with most real-world situations). Folks saw value in having open database maintenance processes (such as the one now used by IANA) and in having multiple sources of time zone information (that can be cross-checked against one another). I trust that other folks will correct and elaborate as appropriate. @dashdashado
On Feb 5, 2019, at 11:39 AM, Arthur David Olson <arthurdavidolson@gmail.com> wrote:
[EXTERNAL EMAIL]
I listened in on today's just-concluded CalConnect event; CalConnect is "the calendaring and scheduling consortium." Just a few notes.
I heard hopes 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 was recognition that the database work is a volunteer effort and that there's a limit to what volunteers can do.
There was mention by an ISO person of ISO's effort to establish a time zone registry with requirements for advance notification of changes; the hope is that the ISO's governmental connections would help encourage compliance.
That's a bit strange. ISO is NOT a government agency, it's an international version of standards bodies like ANSI, or like IETF. It's not clear why ISO would be any more successful at cajoling country governments into early notice than the existing structure. One wonders why ISO is doing this when an existing body does the work already, and has done so effectively for decades. I wonder if the claim is based on reality; has anyone heard of this supposed effort before? If yes, who is doing it and are they communicating with the TZ body? paul
On 2/5/19 8:55 AM, Paul.Koning@dell.com wrote:
One wonders why ISO is doing this when an existing body does the work already, and has done so effectively for decades. I wonder if the claim is based on reality; has anyone heard of this supposed effort before? If yes, who is doing it and are they communicating with the TZ body?
I hadn't heard of the ISO time zone registry effort until today's email from Arthur. (Unfortunately I did not have the time to listen in on the CalConnect meeting myself.) As the ISO hasn't published anything and hasn't contacted us, I imagine that not much work has been done there yet. This reminds me of a similar effort years ago under the aegis of the IETF. In 2005, Doug Royer drafted a Time Zone Registry spec <https://tools.ietf.org/html/draft-royer-timezone-registry-03> that would have registered time zone names with IANA (not meanings; just names). Royer contacted the tz list about this and there was some discussion here in February 2005; the proposal expired in 2006. In practice people nowadays seem to prefer using tzdb names directly to using a separate registry; see, for example, "Calendaring Extensions to WebDAV (CalDAV): Time Zones by Reference", Internet RFC 7809 (2016). The main exceptions I know of are HP-UX and Microsoft Windows, which both have their own registries that predate the popular usage of tzdb (though Microsoft Windows now also supports tzdb to some extent).
It's not clear why ISO would be any more successful at cajoling country governments into early notice than the existing structure.
Yes, it's unlikely that (for example) the government of São Tomé and Príncipe would notify the ISO more reliably than they notify us.
On 2019-02-05 12:33, Paul Eggert wrote:
On 2/5/19 8:55 AM, Paul.Koning@dell.com wrote:
One wonders why ISO is doing this when an existing body does the work already, and has done so effectively for decades. I wonder if the claim is based on reality; has anyone heard of this supposed effort before? If yes, who is doing it and are they communicating with the TZ body?
I hadn't heard of the ISO time zone registry effort until today's email from Arthur. (Unfortunately I did not have the time to listen in on the CalConnect meeting myself.) As the ISO hasn't published anything and hasn't contacted us, I imagine that not much work has been done there yet.
It's not clear why ISO would be any more successful at cajoling country governments into early notice than the existing structure.
Yes, it's unlikely that (for example) the government of São Tomé and Príncipe would notify the ISO more reliably than they notify us.
They might as ISO is a treaty org like ICAO and IATA: govs and their airlines seem to promptly forward TZ and DST updates to local times for schedules and tickets, as the pols would not want to be inconvenienced on their "business" trips. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised.
On Feb 5, 2019, at 3:46 PM, Brian Inglis <Brian.Inglis@SystematicSw.ab.ca> wrote:
On 2019-02-05 12:33, Paul Eggert wrote:
On 2/5/19 8:55 AM, Paul.Koning@dell.com wrote: ...
It's not clear why ISO would be any more successful at cajoling country governments into early notice than the existing structure.
Yes, it's unlikely that (for example) the government of São Tomé and Príncipe would notify the ISO more reliably than they notify us.
They might as ISO is a treaty org like ICAO and IATA: govs and their airlines seem to promptly forward TZ and DST updates to local times for schedules and tickets, as the pols would not want to be inconvenienced on their "business" trips.
My understanding is that ISO is *not* a treaty organization but a non-government body. I notice that the Wikipedia article does not contain the word "treaty". Also, the members of ISO are not countries but national standards organizations; for example, the US member of ISO is ANSI. paul
Quoting Paul.Koning@dell.com on Tuesday February 05, 2019:
Yes, it's unlikely that (for example) the government of São Tomé and Príncipe would notify the ISO more reliably than they notify us.
They might as ISO is a treaty org like ICAO and IATA: govs and their airlines seem to promptly forward TZ and DST updates to local times for schedules and tickets, as the pols would not want to be inconvenienced on their "business" trips.
My understanding is that ISO is *not* a treaty organization but a non-government body. I notice that the Wikipedia article does not contain the word "treaty". Also, the members of ISO are not countries but national standards organizations; for example, the US member of ISO is ANSI.
We work with ISO on some other standards (nothing to do with timezones) and I relayed this discussion to our internal team. Here is some feedback that may be useful from a colleague: Normally the ISO organisation is not running any registry (Maintenance Agency or Registry Authority in ISO speak) by itself. The big exception is MA 3166 (country codes) but for the rest it is done by outside organisations which are officially recognised by ISO. If there are multiple parts, these might actually be served by different registries. An example for ISO 639 (language codes) can be found at UN Infoterm <http://www.infoterm.info>. They list themselves for 639-1, Library of Congress for 639-2 and 639-5, SIL international for 639-3 and Geolang for 639-6 although I think that 639-6 is now withdrawn. As an example of an RA see also <http://www.loc.gov/standards/iso639-2/>. The only ISO standard related to time (-zones) is ISO 8601. That one is owned by TC 154/WG 5 "Representation of dates and times”. CalConnect is a proud liaison A to this TC 154 (and a lot of others, see https://www.calconnect.org/about/liaisons-and-relationships for a complete list and the personnel involved). The TC 154 seems to be very active in updating and extending 8601 (See also https://www.iso.org/news/2017/02/Ref2164.html and https://www.iso.org/organization/6412349.html). It seems that CalConnect is actively involved in this work. And indeed, they have on their site some information about that. At https://www.calconnect.org/about/major-work-projects they seem to be interested in a Timezone service and registry - "Full timezone support via dynamic server calls rather than embedding timezone information in events - no more having event times wrong when timezones change and your software isn't updated”. Since ISO only merely facilitates the development of standards I think that the ISO person mentioned is actually one of the liaisons to TC 154 speaking about the work in WG 5. In short, ISO is a forum for standards development and unlikely to play any operational role in maintaining any speculated registry. This is perhaps akin to the split of responsibilities between the IETF and IANA. kim
On Tue 2019-02-05T14:52:41-0800 Kim Davies hath writ:
In short, ISO is a forum for standards development and unlikely to play any operational role in maintaining any speculated registry. This is perhaps akin to the split of responsibilities between the IETF and IANA.
For comparison with the IANA tz data, the IATA has a database of time zones as an appendix to a document called SSIM. That consists of records of 390 ASCII characters in columns at a cost of $1329.00 USD https://www.iata.org/publications/store/Documents/Passenger%20Standards/spec... SSIM is structured as the offsets currently in effect; history is not included. It is unclear to me why an airline would subscribe to this information rather than rely on IANA tz. -- 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
Some legal issues and validation and verification maybe? On 2/11/19 11:49, Steve Allen wrote:
On Tue 2019-02-05T14:52:41-0800 Kim Davies hath writ:
In short, ISO is a forum for standards development and unlikely to play any operational role in maintaining any speculated registry. This is perhaps akin to the split of responsibilities between the IETF and IANA. For comparison with the IANA tz data, the IATA has a database of time zones as an appendix to a document called SSIM. That consists of records of 390 ASCII characters in columns at a cost of $1329.00 USD https://www.iata.org/publications/store/Documents/Passenger%20Standards/spec...
SSIM is structured as the offsets currently in effect; history is not included. It is unclear to me why an airline would subscribe to this information rather than rely on IANA tz.
-- 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
Le 11/02/2019 à 17:49, Steve Allen a écrit :
For comparison with the IANA tz data, the IATA has a database of time zones as an appendix to a document called SSIM. That consists of records of 390 ASCII characters in columns at a cost of $1329.00 USD https://www.iata.org/publications/store/Documents/Passenger%20Standards/spec...
SSIM is structured as the offsets currently in effect; history is not included. It is unclear to me why an airline would subscribe to this information rather than rely on IANA tz.
Does IANA have access to this IATA data? Can anything be learnt from a regular comparison of offsets? -- John
On 2019-02-12 05:30, John Wilcock wrote:
Le 11/02/2019 à 17:49, Steve Allen a écrit :
For comparison with the IANA tz data, the IATA has a database of time zones as an appendix to a document called SSIM. That consists of records of 390 ASCII characters in columns at a cost of $1329.00 USD https://www.iata.org/publications/store/Documents/Passenger%20Standards/spec... SSIM is structured as the offsets currently in effect; history is not included. It is unclear to me why an airline would subscribe to this information rather than rely on IANA tz.
Info is provided by governments directly to national air operators, and probably also international air operators into those countries, many of whom will be IATA members. This tz db list would like governments to add the tz@iana.org list mailing address to their time change email distribution lists which include air operators.
Does IANA have access to this IATA data? Can anything be learnt from a regular comparison of offsets? If someone wanted to donate the purchase of an annual SSIM licence to the maintainer or IANA, it could be used for reference comparisons. If an --ssim option were added to zdump to produce the same format, comparisons could be produced by licensees. Results could be shared as long as the licensed data were not reproduced verbatim to conform to the licence e.g. a field level comparison could show the IANA data for reference, with only the effects of the differing SSIM fields shown.
A field level diff could easily be produced in any convenient scripting language, by anyone with suitable skills, and access to licensed data for testing. This would be useful to the major software vendors subscribed to this list, who should probably be subscribed to SSIM Appendix F data, to have access to complete and diverse information for verification and validation. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised.
On 2/12/19 4:30 AM, John Wilcock wrote:
Does IANA have access to this IATA data? Can anything be learnt from a regular comparison of offsets?
I lack access to that data. The late Gwillim Law did have access, which I think was published semiannually on paper, and in the 1990s sent us helpful summaries of discrepancies between the IATA data and ours. As I recall the IATA tables did not record time zone histories, though they did have some provision for planned future changes.
Quoting John Wilcock on Tuesday February 12, 2019:
Does IANA have access to this IATA data? Can anything be learnt from a regular comparison of offsets?
We don't, but even if we did arrange for that, it appears the default terms of licensing would preclude sharing its contents for consideration by this group: The Data are licensed, and not sold, to you (“the Licensee”), and may be used within your software applications. This license may not be assigned or transferred by the Licensee to any third party. The Data, in their raw format (ASCII format), shall not be disclosed, given or sold to any third parties. kim
On 2/13/19 4:43 PM, Kim Davies wrote:
it appears the default terms of licensing would preclude sharing its contents for consideration by this group
Actually because we are in the US we could share the IATA's tzdb-relevant information as long as we did it in our own way. It is long-settled US copyright law that although you can copyright your creative representation of data, you cannot copyright data per se, and the IATA license is evidently worded with this in mind.
On Wed, 13 Feb 2019 at 20:21, Paul Eggert <eggert@cs.ucla.edu> wrote:
Actually because we are in the US we could share the IATA's tzdb-relevant information as long as we did it in our own way. It is long-settled US copyright law that although you can copyright your creative representation of data, you cannot copyright data per se, and the IATA license is evidently worded with this in mind.
That might end up being the larger issue, though, as it looks like several of the fields in IATA's data could well require additional lookup tables on our end: namely, Country Name, Time Zone Code, and Time Zone Name, many of which might not have simple mappings to existing tz data. Country names are certainly one thing, of course, but it's probably a bit less well-settled whether an IATA 2-character Time Zone Code is copyrightable, nor whether repackaging such data in our own formats or reproductions constitutes "disclosure" which would be prohibited by the license. I agree the wording seems quite particular, and that's likely for some reason. But IANAL. -- Tim Parenti
Le 14/02/2019 à 01:43, Kim Davies a écrit :
Quoting John Wilcock on Tuesday February 12, 2019:
Does IANA have access to this IATA data? Can anything be learnt from a regular comparison of offsets?
We don't, but even if we did arrange for that, it appears the default terms of licensing would preclude sharing its contents for consideration by this group:
Is it just me being naïve, or is it not possible that official contacts between the two organisations might result in the IATA data being made available for comparison purposes, under conditions more advantageous than the default licence, to the benefit of both parties? -- John
Quoting John Wilcock on Thursday February 14, 2019:
We don't, but even if we did arrange for that, it appears the default terms of licensing would preclude sharing its contents for consideration by this group:
Is it just me being naïve, or is it not possible that official contacts between the two organisations might result in the IATA data being made available for comparison purposes, under conditions more advantageous than the default licence, to the benefit of both parties?
We could always seek custom terms, obviously we have no idea if it would be successful. To me it is a question of how important IATA's data is to this group to support a potentially significant amount of work needed to pursue this. kim
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
On Feb 5, 2019, at 14:52, Steve Allen <sla@ucolick.org> wrote:
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.
Correct, as of RHEL 7. My understanding is that they are moving to vanguard in RHEL 8. I will try to verify that when I load up the beta in the next day or two. Cheers! |---------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |---------------------------------------------------------------------| | A room without books is like a body without a soul. | | | | -- Cicero | |---------------------------------------------------------------------|
* Steve Allen:
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.
Yes, we ship the rearguard format because of compatibility requirements. We tried to change the format in Red Hat Enterprise Linux 8, but we could not do so because too much software was negatively impacted (some of which we could not fix). My understanding is that the necessary API change for Java has yet to happen, for example. We will update the public kbase article on tzdata development to reflect the change of plans for Red Hat Enterprise Linux 8 (although the wording is technically still accurate). Thanks, Florian
participants (11)
-
Arthur David Olson -
Brian Inglis -
Florian Weimer -
Fred Gleason -
John Wilcock -
Kim Davies -
Michael Douglass -
Paul Eggert -
Paul.Koning＠dell.com -
Steve Allen -
Tim Parenti