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

From: Tobias Conradi <[email-masked]>
Date: Wed, 27 Aug 2014 18:06:23 +0200

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.

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.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 28 Aug 2014 10:44:05 -0400

Hi Tobias,

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

> https://datatracker.ietf.org/doc/charter-ietf-tzdist/

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

---

From: Tobias Conradi <[email-masked]>
Date: Thu, 28 Aug 2014 18:08:11 +0200

On Thu, Aug 28, 2014 at 4:44 PM, Cyrus Daboo <[email-masked]> wrote:
> X- ones. In fact the current spec already does register one new property (in
> Section 8): EQUIVALENT-TZID.
Which clause in http://tools.ietf.org/html/rfc5545 regulates that?

Where can one find properties registered after publication of RFC 5545?

> 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:
...
> the last Thursday in September".
"Can" or for RFC 5455 "must"? Does VTIMEZONE allow both, 24:00:00 and 00:00:00 ?

> 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.
There is no possibility to have an offset? What if the rule would be
the first SA 00:00 after the last TH in a month?

If that is not possible then I suggest to supersede RFC 5545 with a
new version, or expand it with a new field.

As above, the easiest starter until proper registration it could go
into a X-TZDIST- namespace, to properly show who controls the
definition of this tag. Long-term this offset has relevance out TZDIST
and also in other components than VTIMEZONE.

> Instead, the tool I wrote had to generate this (*):
>
> 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).
>
> would be very reluctant to consider iCalendar as a possible "canonical" form
> for the tzdb.
It is the only widely supported form. The charter says

"The time zone data distribution protocol will initially be targeted at
iCalendar-based clients"

But if iCalendar is not able to represent this rule directly, which is
easy to write in English prose, i.e. without using BYYEARDAY then
maybe one can change iCalendar.

> (*) 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.
That looks as if 24:00:00 is not allowed and no offset exists.

Here the error is 1 second, but if the rule would be
Rule    Egypt   2014    max     -       Sep     lastThu 48:00   0       -

i.e. Saturday 00:00, the error would be 1 day and 1 second.

-- 
Tobias Conradi
Rheinsberger Str. 18
10115 Berlin
Germany

http://tobiasconradi.com

---

From: Eliot Lear <[email-masked]>
Date: Thu, 28 Aug 2014 18:21:54 +0200

> "Can" or for RFC 5455 "must"? Does VTIMEZONE allow both, 24:00:00 and 00:00:00 ?

byhrlist can only go from 0-23.

I actually think that's a bug because one cannot express all ISO 8601
dates and times.

---

From: Ken Murchison <[email-masked]>
Date: Thu, 28 Aug 2014 12:24:32 -0400

> Where can one find properties registered after publication of RFC 5545?

http://www.iana.org/assignments/icalendar/icalendar.xhtml#properties

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 28 Aug 2014 12:25:19 -0400

Hi Tobias,

--On August 28, 2014 at 6:08:11 PM +0200 Tobias Conradi 
<[email-masked]> wrote:

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

Section 8 of RFC5545 defined a set of IANA registries for all the protocol 
elements used in 5545. For example the registry of property names is here: 
<http://www.iana.org/assignments/icalendar/icalendar.xhtml#properties>, and 
that shows one property - XML - defined after 5545.

>> current tzdb that cannot easily be represented in VTIMEZONE in a way
>> that makes the underlying tzdb rule obvious. To illustrate, consider the
>> following:
> ...

iCalendar itself does not allow 24:00:00 in time values.

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

Well BYYEARDAY/BYDAY does work to cover the case at hand - but some 
implementatiosn don't support it. Introducing a new field would mean no 
existing implementations support it - and that would be a major backwards 
compatibility issue.

> and also in other components than VTIMEZONE.

We can go ahead we "preliminary" registrations in our spec without using 
the X- prefix, which the IETF is actually trying to phase out (see 
<http://tools.ietf.org/html/rfc6648>).

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

As mentioned above - that would be detrimental to backwards compatibility 
to the large deployed base of existing iCalendar products.

>> by having the transition occur at 23:59:59 on the Thursday, which did
>> mean I could use a BYDAY/BYMONTH RRULE.

If something like 48:00 ever appeared my first reaction would be to scream 
:-) In the worst case one can always use RDATEs to express observances - 
with the only downside being that it can only cover a finite range into the 
future, but that is probably OK given the discussions we have had about 
requiring and indication of future truncation.

-- 
Cyrus Daboo

---

From: Ken Murchison <[email-masked]>
Date: Thu, 28 Aug 2014 12:36:18 -0400

On 08/28/2014 12:25 PM, Cyrus Daboo wrote:
> implementatiosn don't support it.

FWIW, I'm in the process of fixing this deficiency in libical which 
should fix a lot of applications once they upgrade to the new version 
(hopefully in release 1.1).

---

From: Paul Eggert <[email-masked]>
Date: Thu, 28 Aug 2014 10:40:45 -0700

> If something like 48:00 ever appeared my first reaction would be to scream

We can make you scream even louder than that. :-)  Starting with tz 
release 2013e, the range of hours supported for DST transitions has been 
extended to -167 through 167.  This is used for some real-world rules 
such as Pacific/Fiji and America/Santiago.  For example, Fiji's future 
rules can be specified by the extended-POSIX TZ string 
'FJT-12:00FJST,M10.3.1/146:00,M1.3.4/75:00', where the 146:00 stands for 
146 hours after the start of the given day.

This new notation in 2013e has been percolating out into the client 
libraries, e.g., the GNU C Library has fully supported it since release 
2.19 in February of this year (it had partial support earlier).

Evidently VTIMEZONE doesn't do this sort of thing, so it sounds like 
VTIMEZONE should get fixed, though I assume this would be outside the 
scope of the tzdist protocol.