New Mail List - timezones.external at software.com

Doug Royer doug at royer.com
Fri Feb 4 16:38:24 UTC 2000


> To: tz at elsie.nci.nih.gov, ietf-calendar at imc.org
> Cc: Doug Royer <doug at home.royer.com>
> Subject: Re: New Mail List - timezones.external at software.com
> X-URL: http://www.cl.cam.ac.uk/~mgk25/
> Date: Fri, 04 Feb 2000 14:47:22 +0000
> From: Markus Kuhn <Markus.Kuhn at cl.cam.ac.uk>
> 
> 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.

Thanks - I did not know what to call it :-)

IANA has stepped up to doing this on the internet. There is now a 
international agreed way to represent timezones on the internet.
And several large vendors (Microsoft, Sun, DEC, HP, IBM, ...) have
agreed to use this format for calendar data. The EUC wants this
format, as does the US internet community.

> There exists already a well-established mailing list for discussions
> on time zones and the maintenance of the Olson database, namely

This list is for converting the data into RFC-2445 format, not
for the discussion of timezones. We plan to use the Olson database
to create the VTIMZONE data. Then IANA will keep the data.

Several countries want an 'official' database, and IANA is where
it is going to be kept.

>   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?

Yes it has, not quite the same job however. We spent about 5 years
coming to agreement on a way to represent this information on
the internet. IANA is NOT going to be the source of the information.
IANA is going to be the official outlet for the information in
the agreed on format.

> 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.

And I suspect those tasks will remain separate. IANA is going to
keep the VTIMEZONE format. It will be the internet standard way
to get the data. Two public domain efforts (Java and C++) are
being written now to process calendar and scheduling information.
And VTIMEZONE will within a year be the official standard format that
internet applications will be using to exchange time related information
across time zones.

> Just dropping the maintenance of the time zone database into the
> responsibility of IANA might give them a task they underestimate at the
> moment.

IANA is going to keep the VTIMEZONE data. *MANY* vendors want
an internet ready version of the data. I suspect in the not to
distant future there will be timezone servers, where with
the help of the tz at elsie.nci.nih.gov list and the Olson database
companies can get timezone information, applications will have
one standard way to exchange information when doing calendaring an
scheduling.

An internet application can then use an URL, (Possible) example:

	TZ://www.iana.org/vtimezone/US/Pacific
	
Or maybe (I am not an HTTP expert) something like:
	
	TZ://www/iana.mirror.../vtimezone/lat?...,lon=?

> 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.

A ZIC -> VTIMEZONE converter is the primary goal of this new list. Once
the goals are accomplished, this new list will go away.

Again, I don't see the ZIC format going away.

> 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.

It's happening to write data to convert to VTIMEZONE. Then
this new list will go away.

> > 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 ...

Please join the IETF mailing list ietf-calendar at imc.org .
Send requests to join to ietf-calendar-request at imc.org .

It is already in 'proposed standard' state. It would take a LOT
of work to change that format at this time. It can be for technical
reasons. If you feel there are some PLEASE comment on the list.

-Doug
-------------------------------------------------------------------
Doug at Royer.COM                  http://royer.com/People/Doug
Text Pager:                     pager at Royer.com
801 W. El Camino #131
Mountain View, CA 94040         Ham Radio: N6AAW, Aviation: PP-ASEL




More information about the tz mailing list