<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 09/07/2016 08:40 PM, Alexander
Belopolsky wrote:<br>
</div>
<blockquote
cite="mid:CAP7h-xakQP39SJ+n-uxYe7T2OQFka5TtcQaFT1bYHoQ-22qsKg@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
On Wed, Sep 7, 2016 at 4:52 PM, Paul Eggert <<a
class="moz-txt-link-abbreviated"
href="mailto:eggert@cs.ucla.edu"><a class="moz-txt-link-abbreviated" href="mailto:eggert@cs.ucla.edu">eggert@cs.ucla.edu</a></a>>
wrote:<br>
><br>
> On 09/07/2016 01:03 PM, Alexander Belopolsky wrote:<br>
>><br>
>> That's clear, but adding an option to zic to generate
timezone data in tzdist format may not be out of reach.<br>
><br>
><br>
> vzic already does that, no?<br>
<br>
<br>
Not really. As far as I can tell, vzic produces a single RFC
2445 vztimezone specification for each IANA zone. All generated
.ics files have the same DTSTART set to 19700101T000000 and RFC
7808 TZUNTIL property is not supported at all.<br>
</div>
</blockquote>
<br>
I have my own "forked" copy of vzic that I use for the tzdist
service that I implemented in Cyrus which fixes a few bugs and plugs
a couple of holes in the vzic that has been out there for a while.
Its handles all rules currently in tzdata in a more compact version
(RRULEs vs RDATEs) than what the stock vzic produces. I intend to
commit this back to either libical which has its own fork of vzic or
back to the "original". You can see an example of what it outputs
here: <a class="moz-txt-link-freetext"
href="https://cyrus-test.andrew.cmu.edu/tzdist/zones/America/New_York">https://cyrus-test.andrew.cmu.edu/tzdist/zones/America/New_York</a><br>
<br>
Note that DTSTART is accurate per tzdata. Also note that TZUNTIL
will only appear if the tzdata itself has a termination date or the
tzdist client asks for a cropped version of the time zone: <a
href="https://cyrus-test.andrew.cmu.edu/tzdist/zones/America/New_York?start=20160101T000000Z&end=20200101T000000Z"><a class="moz-txt-link-freetext" href="https://cyrus-test.andrew.cmu.edu/tzdist/zones/America/New_York?start=20160101T000000Z&end=20200101T000000Z">https://cyrus-test.andrew.cmu.edu/tzdist/zones/America/New_York?start=20160101T000000Z&end=20200101T000000Z</a></a><br>
<br>
<br>
<blockquote
cite="mid:CAP7h-xakQP39SJ+n-uxYe7T2OQFka5TtcQaFT1bYHoQ-22qsKg@mail.gmail.com"
type="cite">
<div dir="ltr"> <br>
> Do we need to reinvent that wheel?
<div><br>
</div>
<div>For some reason vzic author had to reinvent the wheel and
write his own zone file parser. This part does not need to be
reinvented. Since zic already knows how to translate rules to
POSIX TZ string format, translating to iCalendar RRULE does
not seem to require a lot of code. However, what I had in
mind was that zic could implement the RFC 7808 "expand" action
<<a moz-do-not-send="true"
href="https://tools.ietf.org/html/rfc7808#section-5.4">https://tools.ietf.org/html/rfc7808#section-5.4</a>>
which is not implemented in vzic.</div>
</div>
</blockquote>
<br>
"expand" is closer to what zdump does than vzic. In fact, I
implemented this format with the expand action in my server to
compare against zdump -V to make sure that what my copy of vzic
generates matches what is expected: <a
href="https://cyrus-test.andrew.cmu.edu/tzdist/zones/America/New_York/observances?start=18000101T000000Z&end=20400101T000000Z&format=application/zdump"><a class="moz-txt-link-freetext" href="https://cyrus-test.andrew.cmu.edu/tzdist/zones/America/New_York/observances?start=18000101T000000Z&end=20400101T000000Z&format=application/zdump">https://cyrus-test.andrew.cmu.edu/tzdist/zones/America/New_York/observances?start=18000101T000000Z&end=20400101T000000Z&format=application/zdump</a></a><br>
<br>
<br>
<br>
<pre class="moz-signature" cols="72">--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University
</pre>
</body>
</html>