Some reactions in-line. paul
-----Original Message----- From: Mike Douglass [mailto:douglm@rpi.edu] Sent: Thursday, August 27, 2009 9:56 To: tz@lecserver.nci.nih.gov Subject: RE: New home for time zone stuff by 2012?
The Calendaring and Scheduling Consortium (CalConnect), through a number of activities over time, has demonstrated an active interest in addressing problems related to timezones for calendaring and scheduling systems for a while. The standards in this space, namely iCalendar, were developed by the Internet Engineering Task Force (IETF). A number of issues have spurred this work within CalConnect, including (but not limited to) the US EDST changes from 2007.
As "consumers" of timezone data (rather than "producers" - which relates to the job done by the community represented by this mailing list, tz@elsie.nci.nih.gov) we are eager to see a reliable, timely and secure process for handling timezones.
In CalConnect's Timezone Technical Committee (TC), we are presently developing a timezone service protocol that will allow for direct updates of client systems, rather than relying on the current process where systems typically get updated via OS upgrades, if at all. As part of this effort, we are also developing a generic timezone description format in XML so that interchange of timezone data can be done efficiently, and so that we can include structured meta-data like KML for boundary information.
A timezone service sounds like a good idea. It raises a bunch of questions, though. Security would be far more of an issue with such an approach as opposed to the current approach of relying on (and benefiting from) a secure OS distribution scheme. Scaleability could be a big problem. Consider every PC in the world polling such a server once a day for updates... Embedded systems and systems in closed networks still need the existing scheme, because they either can't or don't want to connect to a timezone service. XML is a nice and flexible interchange format. It usually isn't very efficient but probably efficient enough. It also is very bulky compared to the current format. Again, consider embedded systems. In a system I work on, we can't possibly store the current tzdata format in full, let alone what it would look like if expressed in XML. We solved that by modifying the tz compiler to omit any historic data prior to V1.0, since the nature of this product is that it never has to show times predating its release. With that change, the data fits (it shrinks down to less 200 kbytes, which is acceptable.
CalConnect would like to see a formal "standardization" of timezone names with a registry. This issue has been a problem in the iCalendar space where presently it is difficult to rely on a timezone definition with a given name, often resulting in interoperability problems. CalConnect would like to see timezone data passed "by reference" rather than "by value" for efficiency purposes (iCalendar requires that a VTIMEZONE component always be included in the iCalendar data stream when a timezone is referenced by an event).
I believe it has been generally recognized that standardized timezone names is a pipe dream. The abbreviated names are hopelessly ambiguous, and even ignoring that there isn't an authority standardizing them. The long names (like "America/New York") used in the tzdata are unambiguous. But they change occasionally as countries change city names. Then again, the tzdata contains links from the old to the new names, so the old names remain valid. That seems to be the best one could hope to achieve, and it's here now. What does "by reference" and "by value" mean in the context of timezone data? I can't figure out the meaning here.
Earlier this year, CalConnect hosted a timezone workshop at one of its face-to-face Roundtables. The primary focus of the workshop was to discuss the problem statement and development of the protocol, data format and registry process. Since then we have also initiated discussions in the IETF on these topics.
As "consumers" of timezone data CalConnect feels strongly about the need for these improvements. None of this necessarily impacts the process of "producing" timezone data as carried out by this list's community. Nonetheless, we care greatly about the "production" process because we have to rely on this data.
We have informally discussed within the CalConnect Timezone TC what we would like to see for the future of the timezone data. We have not come to any firm conclusions as to the best way forward. Mr. Olson's email, therefore, comes as a timely reminder that this needs to be addressed now.
Possible options (as already indicated by Mr. Olson) include:
- Moving it to an "open source" location (such as SourceForge, which has been already suggested) - Setting up some kind of open consortium of interested parties to manage timezone data - Moving responsibility to an existing standards body (e.g., the IETF or the Internet Society - ISOC) - Moving responsibility to a government entity (e.g., the UN)
Unfortunately, this debate can easily get mired in "politics" rather than technical issues. e.g., who gets to control the data, how is the service paid for, who gets to contribute.
Indeed. I believe an open process is critical. The current process is an example, but it depends in large part on the efforts of one person. A consortium formed for the purpose seems like it would work. The IETF is clearly also qualified to do it, and has a properly open process. The question is whether it would want to do it, or whether it would consider it out of charter. A government entity seems like a recipe for disaster.
At the end of the day, CalConnect favors an approach which results in the least amount of disruption. The open community process developed via this list's community has clearly been a success, and should be considered as a potential model going forward.
CalConnect considers tightening up of the security of the timezone data to be essential. Given that many systems rely on the data being produced, we collectively need a secure distribution (i.e. a secure, reliable server, signed data etc). Whilst there have not been any obvious "attacks" against timezone data, one cannot assume there won't be any in the future. This is a propitious time to achieve consensus on the best way to secure the data. This may very well impose additional requirements on hosting the data in the future, e.g., cost of maintaining the server, signing certificates etc).
I agree that signed data would be worth having. This need not add any cost; while SSL certificates may be expensive, PGP ones are free and widely used in the open source community. paul