New Mail List - timezones.external at software.com

Greg FitzPatrick gf at medianet.org
Fri Feb 4 16:53:27 UTC 2000


There is obviously a lot to what you are saying Markus, but one point
remains to be resolved.  In the near future we are going to need legal
frameworks for access to machine-readable online resources.  Maybe that is
part of the effort Doug is talking about

And we are going to need mechanisms for creating and maintaining
aggregations such as the Olson, but that have some official binding to an
Authority.

Because otherwise people wont know who to sue!

BTW the IETF has a parent organization - ISOC, whose raison d´etre is to
protect the IETF  from the legal repercussions of their standards work.

Though it may seem ludicrously utopian at this time to plan for a network of
little bots zipping around from the Cook Islands to the Kingdom of Swat,
slurping up time zone rulings from each individual authority's machine
readable time zone database, that is exactly where we are heading, er,
eventually :-)

Compare that to this:

In Sweden, 78 district courts publish bankruptcy proceedings in a
machine-readable metadata format, any agent may crawl these sites or their
aggregations at regional levels and undertake actions on behalf of their
users based on their readings from these sites without any human
interference or approval.

One government chartered authorities site is charged with the official
machine-readable publishing of an aggregation of all 78 district courts.
Thousand of applications will undertake actions on their users behalf based
on their readings of this information, again with no human intermediation.

This is a non-utopian proposal which we are currently working on.

Depending on the degree of sophistication of each authorities infostructure,
bit for bit information will be transferred to machine collectable, machine
readable authoritive publishing.  Since there is already a sufficient level
of sophistication in some areas of the world such as the Kingdom of Sweden
to go forward with this work, I argue that we should do so and let The
Kingdom of Swat catch up when they can, which will of course guarantee lots
of exciting detective work for the next 50 years.

Agree on a machine readable publishing format and I will pop over to the
Department of Commerce and convince them to publish the official daylight
savings times of Sweden just to be the first ever to do so:-)

Greg

/btw that last paragraph was a gross exaggeration of my power to get things
done here:-)



> Doug Royer <doug at home.royer.com>:
> > There are three goals of this list.
> >
> > 	1) Port the government database and 'zic' (Zone Information
> Compiler)
> > 	   to other OS's and have it also provide the data in VTIMEZONE
> > 	   format. Most UNIX's use the government database format
> and the zic
> > 	   compiler (man zic).
> >
> > 	2) Convert the government database into VTIMEZONE records for IANA
> > 	   to administer.
> >
> > 	3) Give away the results to the public domain.
>
> There might be a few misunderstandings involved here. First, there is no
> "government timezone database". What you see on
> ftp://elsie.nci.nih.gov/pub/
> is the collaboration of a number of volunteers (Arthur Olson, Paul
> Eggert, et al.), the result of which is commonly referred to as the
> public domain "Olson database". The only relation to the US government
> is that the group has been using an ftp server of the National Cancer
> Institute, which happens to be located in the .gov domain.
>
> There exists already a well-established mailing list for discussions
> on time zones and the maintenance of the Olson database, namely
>
>   tz at elsie.nci.nih.gov
>
> Contact
>
>   tz-request at elsie.nci.nih.go
>
> to join the club.
>
> Since there is a lot of accumulated expertise on this mailing list,
> handing over the administration of the database to IANA seems to be a
> rather dubious buerocratic effort. Who at IANA would take over authority
> over the database and is really comparably qualified to the current
> contributors of the Olson database who have done a splendid job for
> the last 15 years?
>
> Please understand that IANA is a registration service, while what the
> group around Olson is doing is more a detective service that observes
> and documents the highly complicated world of national and regional
> decisions about time-zone changes in the world. If government X is going
> to change its local time zone, it is more likely that the database
> maintainer will hear about this from various informers or media reports
> around the world, as well as resources such as IATA or CIA. It is much
> less likely that the respective countries will report timezone changes
> directly to IANA officially. A detective service can provide a more
> accurate representation of the real world than a registration service.
>
> Just dropping the maintenance of the time zone database into the
> responsibility of IANA might give them a task they underestimate at the
> moment.
>
> If you don't like the current zic format, feel free to add a zic->
> VTIMEZONE format converter to the Olson package. Looks mostly like a
> bijective transform to me, except that the zic input files contain a lot
> of valuable comments that identify official reference documents.
>
> Only if the output of that converter on the regular updates of the Olson
> package turns out to be unsatisfactory, I would start worrying about
> setting up a parallel bureaucracy and an independent database. I see
> really no need for yet another mailing list.
>
> > RFC-2445 defines VTIMEZONE.
>
>      BEGIN:VTIMEZONE
>      TZID:US--Fictitious-Eastern
>      LAST-MODIFIED:19870101T000000Z
>      BEGIN:STANDARD
>      DTSTART:19671029T020000
>      RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
>      TZOFFSETFROM:-0400
>      TZOFFSETTO:-0500
>      TZNAME:EST
>      END:STANDARD
>      BEGIN:DAYLIGHT
>      DTSTART:19870405T020000
>      RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z
>      TZOFFSETFROM:-0500
>      TZOFFSETTO:-0400
>      TZNAME:EDT
>      END:DAYLIGHT
>      BEGIN:DAYLIGHT
>      DTSTART:19990424T020000
>      RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=4
>      TZOFFSETFROM:-0500
>      TZOFFSETTO:-0400
>      TZNAME:EDT
>      END:DAYLIGHT
>      END:VTIMEZONE
>
> If people really think that this looks that much nicer or easier to
> parse for machines and humans ...
>
> Markus
>
> --
> Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
> Email: mkuhn at acm.org,  WWW: <http://www.cl.cam.ac.uk/~mgk25/>
>
>




More information about the tz mailing list