Subject: [Tzdist] How should tzdist support rscale?

From: Jonathan Lennox <[email-masked]>
Date: Mon, 5 Jan 2015 17:01:02 -0500

(Cc'ing both tzdist and calsify because the issue is about the interaction
of specs defined by the two groups...please trim to one or the other if the
topic ends up being unique to that group.)

A question recently occured to me about the interaction of rscale and tzdist.

Should it be possible for a VTIMEZONE -- either inline in an iCalendar
document, or distributed by tzdist -- to use an RSCALE?

There are some natural use cases for this -- Iran uses the Persian calendar
to set its DST observances, and Israel used the Hebrew calendar from
2005-2012.  Right now the IANA tzdata just expands non-Gregorian rules to a
list of dates, but in principle, RSCALE would be a much more natural (and
compact) way of representing rules like these.

However, tzdist has no way to negotiate the use of iCalendar extensions.
Should one be defined?

For that matter, the rscale draft doesn't talk about its use in VTIMEZONE
at all (indeed, it asserts that VTIMEZONEs are always specified in Gregorian
time).  Should it?

-- 
Jonathan Lennox
[email-masked]

---

From: Doug Royer <[email-masked]>
Date: Mon, 05 Jan 2015 16:49:46 -0700

> topic ends up being unique to that group.)
That's such a complex topic, as you have been thinking about it, perhaps 
you should compose and send a draft?

-- 

Doug Royer - (http://K7DMR.us / http://DougRoyer.US)
[email-masked]
714-989-6135

---

From: Lester Caine <[email-masked]>
Date: Tue, 06 Jan 2015 00:20:36 +0000

> you should compose and send a draft?

Since TZ is already truncated to a Gregorian calendar I'd view better
calendar support in the same extension as pre-1970 data. Something that
many people need, but which is not 'tasked' to be provided via TZ. We do
need better support for a whole range of material relating to calendar
and time but currently TZ is not the place to provide that core data :(
We need a base to maintain everything which is not specifically within
the narrow window that TZ provides.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

---

From: Cyrus Daboo <[email-masked]>
Date: Tue, 06 Jan 2015 10:24:13 -0500

Hi Jonathan,

> document, or distributed by tzdist -- to use an RSCALE?

If a time zone were indeed defined in terms of a non-Gregorian recurrence 
then it would seem reasonable to support that.

> There are some natural use cases for this -- Iran uses the Persian
> calendar to set its DST observances, and Israel used the Hebrew calendar
> from 2005-2012.  Right now the IANA tzdata just expands non-Gregorian
> rules to a list of dates, but in principle, RSCALE would be a much more
> natural (and compact) way of representing rules like these.
>

If tz data publishers actually start wantint to produce data using 
non-Gregorian rules, then we can easily define an extension to the 
capabilities response to indicate that is an option.

> at all (indeed, it asserts that VTIMEZONEs are always specified in
> Gregorian time).  Should it?

Actually the rscale document only mentions time zones once in Section 1 - 
and there it states that time zone rules (i.e., what comes from a 
publisher) is specified in terms of the Gregorian calendar - that does not 
imply VTIMEZONE itself is limited to Gregorian rules - just that no time 
zone data uses non-Gregorian. If you think that text needs re-wording to 
clarify that, I can certainly change it.

At this point, I think the use of non-Gregorian rules in VTIMEZONE should 
not be ruled out, but tzdist does not need to support it until we have 
publishers actually wanting to use it. Of course at that point things will 
get tricky for the publisher as they will want to keep the Gregorian rules 
around for backwards compatibility.

-- 
Cyrus Daboo

---

From: Lester Caine <[email-masked]>
Date: Tue, 06 Jan 2015 15:41:52 +0000

On 06/01/15 15:24, Cyrus Daboo wrote:
> At this point, I think the use of non-Gregorian rules in VTIMEZONE
> should not be ruled out, but tzdist does not need to support it until we
> have publishers actually wanting to use it. Of course at that point
> things will get tricky for the publisher as they will want to keep the
> Gregorian rules around for backwards compatibility.

version takes care of that on one level, but just as the binary TZ data
uses different TZid's for with or without leapseconds, calendar would
potentially become part of the id? Essentially which ever method of
describing a data set is used it has to match every other method?

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 7 Jan 2015 13:21:54 -0500

> clarify that, I can certainly change it.

Yes, I think that the rscale draft should be clarified to note that RSCALE
can appear in an RRULE in any iCalendar context where RRULE is allowed, not
just VEVENT, and in particular it can appear in VTIMEZONE.

> around for backwards compatibility.

Yes -- for tzdist I'm mostly thinking about this as an exercise to make sure
we have backward-compatible future extensibility defined correctly.  If we
understand how we would do this if it's ever needed, I think we're in pretty
good shape.

That said, I think tzdist in the meantime should have some statement saying
that RSCALE MUST NOT be used unless support for it is negotated through some
as-yet undefined mechanism.

-- 
Jonathan Lennox
[email-masked]

---

From: Jonathan Lennox <[email-masked]>
Date: Wed, 7 Jan 2015 14:21:04 -0500

> just VEVENT, and in particular it can appear in VTIMEZONE.

The new text in version -03 of rscale satisfies this nicely. Thank you!
-- 
Jonathan Lennox
[email-masked]