Web service time computer
Phillip.Guerra at nkch.org
Fri Feb 24 19:08:09 UTC 2006
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
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
From: Markus Kuhn [mailto:Markus.Kuhn at cl.cam.ac.uk]
Sent: Friday, February 24, 2006 11:49 AM
To: tz at 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
"DST shall henceforth start on the first Monday
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."
More information about the tz