<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi,
<p>Since I'm on both ietf-calendar (<A HREF="http://www.imc.org/ietf-calendar/">http://www.imc.org/ietf-calendar/</A>)
and a lurker on the tz mailing list (<a href="ftp://elsie.nci.nih.gov/pub/">ftp://elsie.nci.nih.gov/pub/)</a>,
perhaps I can offer a bit of clarification here.  As everyone on both
lists realizes, timezones is one of the major "gotchas" of scheduling.
<p>The tz list is indeed focused on the detective work of determining the
changes in timezones, both historical and current.  The ietf-calendar
list is focused on developing the standard representation of calendar data 
and the protocols to allow calendar applications to share calendar data
easily.
<p>In order to ensure that two calendar implementations can interoperate,
both need to look at the same database of timezones.   Since
we're drafting the CAP (Calendar Access Protocol) now, we need to point
Calendar implementors at a timezone standard, which of course doesn't exist.
<p>The TZ database appears to be the closest thing available, an excellent
example of volunteers doing a much needed job.   The problem
is how to reference it in an RFC?
<p>I won't speak for Doug, but I believe he intended to leverage the tz
mailing list and the packaged updates, but use the IANA as the "official"
repository for standards to reference.   The current tzdata ftp
site, a US government organization which has nothing to do with timezones,
doesn't allow web pages.   Why not find a permanent home for
this with the IANA (www.iana.org) which has "Dedicated to preserving the
central coordinating functions of the global Internet for the public good"
as its motto.
<p>dmadeo
<br> 
<p>Markus Kuhn wrote:
<blockquote TYPE=CITE>There might be a few misunderstandings involved here.
First, there is no
<br>"government timezone database". What you see on <a href="ftp://elsie.nci.nih.gov/pub/">ftp://elsie.nci.nih.gov/pub/</a>
<br>is the collaboration of a number of volunteers (Arthur Olson, Paul
<br>Eggert, et al.), the result of which is commonly referred to as the
<br>public domain "Olson database". The only relation to the US government
<br>is that the group has been using an ftp server of the National Cancer
<br>Institute, which happens to be located in the .gov domain.</blockquote>

<blockquote TYPE=CITE>Since there is a lot of accumulated expertise on
this mailing list,
<br>handing over the administration of the database to IANA seems to be
a
<br>rather dubious buerocratic effort. Who at IANA would take over authority
<br>over the database and is really comparably qualified to the current
<br>contributors of the Olson database who have done a splendid job for
<br>the last 15 years?
<p>Just dropping the maintenance of the time zone database into the
<br>responsibility of IANA might give them a task they underestimate at
the
<br>moment.
<p>If you don't like the current zic format, feel free to add a zic->
<br>VTIMEZONE format converter to the Olson package. Looks mostly like
a
<br>bijective transform to me, except that the zic input files contain
a lot
<br>of valuable comments that identify official reference documents.
<p>Only if the output of that converter on the regular updates of the Olson
<br>package turns out to be unsatisfactory, I would start worrying about
<br>setting up a parallel bureaucracy and an independent database. I see
<br>really no need for yet another mailing list.
<p>> RFC-2445 defines VTIMEZONE.
<p>     BEGIN:VTIMEZONE
<br>     TZID:US--Fictitious-Eastern
<br>     LAST-MODIFIED:19870101T000000Z
<br>     BEGIN:STANDARD
<br>     DTSTART:19671029T020000
<br>     RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
<br>     TZOFFSETFROM:-0400
<br>     TZOFFSETTO:-0500
<br>     TZNAME:EST
<br>     END:STANDARD
<br>     BEGIN:DAYLIGHT
<br>     DTSTART:19870405T020000
<br>     RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z
<br>     TZOFFSETFROM:-0500
<br>     TZOFFSETTO:-0400
<br>     TZNAME:EDT
<br>     END:DAYLIGHT
<br>     BEGIN:DAYLIGHT
<br>     DTSTART:19990424T020000
<br>     RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=4
<br>     TZOFFSETFROM:-0500
<br>     TZOFFSETTO:-0400
<br>     TZNAME:EDT
<br>     END:DAYLIGHT
<br>     END:VTIMEZONE
<p>If people really think that this looks that much nicer or easier to
<br>parse for machines and humans ...
<p>Markus
<p>--
<br>Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
<br>Email: mkuhn at acm.org,  WWW: <<a href="http://www.cl.cam.ac.uk/~mgk25/">http://www.cl.cam.ac.uk/~mgk25/</a>></blockquote>
</html>