If the rule Markus presents is enacted anywhere, exactly how would that fit into the present coding scheme? :) I would not champion changing the master format, but do feel alternate formats could be made available for use with disparate systems. Yes, many folks have to program for more than 1 operating system and the effort would be worthwhile to keep the current datastore as the common standard. I won't argue for presentation of an xml version for the sake of stability, but rather would think the issue is making the datastore easier to integrate into other systems. Is XML the best format? I wouldn't say, but having spent a great deal of time parsing and converting many healthcare related datasets from one system to another, it was really an improvement to see HL7 introduced years ago. Something similar would be appreciated with this type of information, maybe not exactly XML, but a protocol that allows greater flexibility for use in sharing info between disparate systems. Once the metadata is transferred, a 'conversion' utility can be used to put it into a form most efficient for the host or target system. Web administrators need a common approach to the issue of presenting date time and date time interpolation that are not bound to operating systems, and a host machines' registry. It's an issue that is shared with users of all types of operating systems. I don't care about a programmers preference, use what you need, but at least have a common datastore for needed elements. At present, I'm using the tzinfo datastore, and parsing it for use on a Windows .Net framework. An alternate format would have been nice to use, as it was a challenge to get my head and arms around the format of the datastore not knowing about the zic utility, or other Posix type languages. My lack of skills in those areas is at fault not the datastores' exactly. I'll continue to use the tzinfo datastore in the current format because I believe it is the closest to fullfilling the need for common usage. However, I do see positives for presenting alternate formats using a common metadata. Cheers -----Original Message----- From: Markus Kuhn [mailto:Markus.Kuhn@cl.cam.ac.uk] Sent: Friday, February 24, 2006 11:49 AM To: tz@lecserver.nci.nih.gov Subject: Re: Web service time computer 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