It might be better to maintain TZDATA in xml and have a translator back to the current format. ++PLS -----Original Message----- From: tz-request@elsie.nci.nih.gov [mailto:tz-request@elsie.nci.nih.gov] On Behalf Of Deborah Goldsmith Sent: Thursday, February 23, 2006 1:00 PM To: tz@lecserver.nci.nih.gov Subject: Re: Web service time computer On Feb 23, 2006, at 8:59 AM, Andy Lipscomb wrote:
I've actually been trying to use this data to implement time zone conversion in REALbasic, and one of the steps in doing so has proven to be rewriting the data files in XML. I could contribute that much to
the efforts.
Actually, the ICU team is very interested in getting this data in an XML form as well. One of the projects on my to-do list is to make a proposal for changes to zic that would optionally emit a (stable) XML version of the data. If someone else gets to this first I would be happy to help. Deborah Goldsmith Internationalization, Unicode liaison Apple Computer, Inc. goldsmit@apple.com
"Paul Schauble" wrote on 2006-02-23 20:59 UTC:
It might be better to maintain TZDATA in xml and have a translator back to the current format.
And the advantage would be what exactly? Lot's more < > and pointless nesting to bloat the files and make them (and their diffs) far less readable and far more cumbersome to parse? Buzzword compliance? Please don't! As far as file formats are concerned, XML is near the awkward end of the spectrum. The current tz format does its job quite nicely. People can trivially convert them locally into whatever DTD they prefer this week, if their boss insists on SGML. Markus -- Markus Kuhn, Computer Laboratory, University of Cambridge http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain
On Feb 24, 2006, at 1:35 AM, Markus Kuhn wrote:
It might be better to maintain TZDATA in xml and have a translator back to the current format.
And the advantage would be what exactly?
Stability, so that tools that parse the data can deal with change more gracefully. The ICU project has had a difficult time keeping up with changes to the file and tools. We can't use the output files -- which *are* stable -- because they do not contain all the data from the input that ICU needs. However, I don't care whether the "master" copy is XML or not, just that it is possible to generate XML (or some other stable format) from the "official" version of zic, so that when the timezone file format changes, or zic changes, the stable format doesn't change. Deborah Goldsmith Internationalization, Unicode Liaison Apple Computer, Inc. goldsmit@apple.com
Deborah Goldsmith wrote on 2006-02-24 15:13 UTC:
On Feb 24, 2006, at 1:35 AM, Markus Kuhn wrote:
It might be better to maintain TZDATA in xml and have a translator back to the current format.
And the advantage would be what exactly?
Stability, so that tools that parse the data can deal with change more gracefully. The ICU project has had a difficult time keeping up with changes to the file and tools. We can't use the output files -- which *are* stable -- because they do not contain all the data from the input that ICU needs.
However, I don't care whether the "master" copy is XML or not, just that it is possible to generate XML (or some other stable format) from the "official" version of zic, so that when the timezone file format changes, or zic changes, the stable format doesn't change.
I understand. But also consider that if the timezone file format changes, there may be a good reason for such a change, i.e. a newly required functionality. We are at the mercy of creative politicians all over the world, who continue to think up new and innovative ways for fiddling with local time. They will be as little restricted by your desired XML DTD as they are currently restricted by the zic input file format. "DST shall henceforth start on the first Monday after the first Tuesday after the latest Wednesday before the full moon closest to Easter, exept if the year is divisible by 400, in which case we follow the European Union rules of 1992." Markus
Deborah Goldsmith <goldsmit@apple.com> writes:
We can't use the output files -- which *are* stable
No, actually they're not. Their format just got changed in a big way, to support 64-bit time_t transitions. It's an upward-compatible change, but it's a big one nonetheless, and all binary file readers should upgrade well before 2038.
The ICU project has had a difficult time keeping up with changes to the file and tools.
Hmmm, what changes caused these difficulties, exactly? Here are all the changes to the tz textual format made in the last 20 years that I know about. Perhaps I'm missing something, but if so I'd like to know. * Removal of double leap seconds in 1994 (these were an error). * Removal of the "uspres" feature in 1994 (a never-used feature in real tz data). * Support for the "u" suffix (for universal time) added in 1994. * Support for the "STD/DST" notation, added in 1995. * The clock-advance/clock-retreat fixup of 1996. * Support for "24:00", added in 1998. (Not yet used by tz data.) * Support for out-of-month-range transitions like "Sun<=1" and "Sun>=31", added in 2004. (Not yet used by tz data.) Given this list, I am skeptical whether switching to an XML-based format would improve stability. (If anything, I suspect the reverse would happen.) There are some practical advantages to supporting an XML-based format, but I don't see stability as being one of them.
participants (4)
-
Deborah Goldsmith -
Markus Kuhn -
Paul Eggert -
Paul Schauble