Re: [Tzdist] Proposal to use iCalendar format as basis for field definitions

Cyrus Daboo <cyrus@daboo.name> Thu, 28 August 2014 14:44 UTC

Date: Thu, 28 Aug 2014 10:44:05 -0400
From: Cyrus Daboo <cyrus@daboo.name>
To: Tobias Conradi <tc@tobiasconradi.com>, tzdist@ietf.org, Lester Caine <lester@lsces.co.uk>
Message-ID: <FF0FFAC2A8EDF48EA8EAF2A8@caldav.corp.apple.com>
In-Reply-To: <CAAGevbX9yG8yuq1r=h0NDAMsgBbBHqtY0e6sfQWp3RDBgLLK7w@mail.gmail.com>
References: <CAAGevbX9yG8yuq1r=h0NDAMsgBbBHqtY0e6sfQWp3RDBgLLK7w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size="3310"
Archived-At: http://mailarchive.ietf.org/arch/msg/tzdist/0ApmClCtIzV2hqKn8ASHOD9JEak
Subject: Re: [Tzdist] Proposal to use iCalendar format as basis for field definitions
Precedence: list

Hi Tobias,

--On August 27, 2014 at 6:06:23 PM +0200 Tobias Conradi 
<tc@tobiasconradi.com> wrote:

> I propose that any tzdist specific fields that refer to one time zone
> are defined in the iCalendar format as defined in RFC 5545
> http://tools.ietf.org/html/rfc5545 .
>
> I propose to use
> X-TZDIST-
> as prefix for tzdist specific fields.

If it becomes necessary to extend VTIMEZONE to support additional meta-data 
that is fine - but we should do so with properly registered properties not 
X- ones. In fact the current spec already does register one new property 
(in Section 8): EQUIVALENT-TZID.

> That ensures that the charter requirement
> https://datatracker.ietf.org/doc/charter-ietf-tzdist/
> -------------
> The working group will work under the following parameters:
>
> - The time zone data distribution protocol will initially be targeted at
> iCalendar-based clients
> ---------------
> is fulfilled.

I also want to point out that VTIMEZONE has limitations on conveying the 
underlying tzdb rules in its own RRULEs. There are some rules in the 
current tzdb that cannot easily be represented in VTIMEZONE in a way that 
makes the underlying tzdb rule obvious. To illustrate, consider the 
following:

- For America/New-York the current VTIMEZONE RRULE for the transition to 
standard time is:

RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=11

and the equivalent tzdb rule is:

Rule	US	2007	max	-	Nov	Sun>=1	2:00	0	S

So there is an obvious mapping for "first Sunday in November" between those 
two.

- Now consider the tzdb rule for Egypt:

Rule	Egypt	2014	max	-	Sep	lastThu	24:00	0	-

That is "midnight - at the end of the day - for the last Thursday in 
September". That can also be translated to "the 00:00 on the Friday after 
the last Thursday in September". That exposes the problem - because it is 
possible that the Friday is actually the 1st October if the last Thursday 
in September is the 30th. That "bumps" the recurrence into the next month. 
That makes it impossible to use a BYMONTH type component in the iCalendar 
RRULE. Instead, the tool I wrote had to generate this (*):

RRULE:FREQ=YEARLY;BYDAY=FR;BYYEARDAY=-92,-93,-94,-95,-96,-97,-98

That basically matches the tzdb rule by targeting the week, offset from the 
end of the year, where the observance should occur and picking the day 
within that week. There are other ways to represent that (e.g., usiong 
RDATEs for the exceptions where the Friday is in October and breaking up 
the RRULE into segments in between the RDATEs, but that can only be done to 
some finite point in the future).

Obviously that RRULE now looks nothing like the original tzdb one. So I 
would be very reluctant to consider iCalendar as a possible "canonical" 
form for the tzdb.

(*) I should point out that my tool does not generate the BYYEARDAY rule 
any more. We discovered that another popular iCalendar library does not 
allow the combination of BYDAY and BYYEARDAY parts (even though that is 
legitimate according to RFC5545). To work around that I "broke" the rule a 
little bit by having the transition occur at 23:59:59 on the Thursday, 
which did mean I could use a BYDAY/BYMONTH RRULE. Whilst not ideal it is 
something we are willing to live with in our product until the problems 
with the other library are fixed.

-- 
Cyrus Daboo

[Tzdist] Proposal to use iCalendar format as basi… Tobias Conradi
Re: [Tzdist] Proposal to use iCalendar format as … Cyrus Daboo
Re: [Tzdist] Proposal to use iCalendar format as … Tobias Conradi
Re: [Tzdist] Proposal to use iCalendar format as … Eliot Lear
Re: [Tzdist] Proposal to use iCalendar format as … Ken Murchison
Re: [Tzdist] Proposal to use iCalendar format as … Cyrus Daboo
Re: [Tzdist] Proposal to use iCalendar format as … Ken Murchison
Re: [Tzdist] Proposal to use iCalendar format as … Paul Eggert