Subject: [calsify] draft-daboo-icalendar-rscale and "L" suffix

From: Ken Murchison <[email-masked]>
Date: Fri, 11 Apr 2014 12:44:21 -0400

All,

A couple of random thoughts as I attempt to add RSCALE support to libical:

1)  Maybe I'm missing the point of the "L" suffix, but shouldn't the 
RRULE in example 4.2.3 include the "L" suffix?  E.g.:

RRULE:RSCALE=HEBREW;FREQ=YEARLY;BYMONTH=6*L*;BYMONTHDAY=8;SKIP=FORWARD

If not, can an example be added that includes the "L" suffix?  In either 
case, I'm thinking an example or two of a non-yearly recurrence might be 
helpful.

2)  Also, if I understand SKIP correctly, can the handling of the 
Gregorian leap day (Feb 29) be changed from the non-RSCALE behavior by 
using RSCALE=GREGORIAN;SKIP=BACKWARD/FORWARD?  If so, perhaps an example 
of this is also warranted, such as (borrowed from one of the CalConnect 
etherpads):

DTSTART:20120229T120000Z
RRULE:RSCALE=GREGORIAN;SKIP=FORWARD;FREQ=YEARLY;UNTIL=20140301T115959Z

Occurs:
20120229T120000Z
20130301T120000Z

Does not occur:
20140301T120000Z

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 14 Apr 2014 12:03:42 -0400

Hi Ken,

> case, I'm thinking an example or two of a non-yearly recurrence might be

In most calendar systems with a leap month, months are counted 1 through 
12, with the leap month being tagged with the "L" suffix where it appears 
during the year. In the Hebrew calendar implementation in the unicode ICU 
library, the months are actually numbered 1 through 13. In non-leap years, 
month number 6 is simply skipped. That is already described in section 4.1 
of the current draft.

Now, I suspect from an implementation standpoint, one might want to use 
isLeapYear(N) as the trigger for adding the "L" suffix and I suspect (but 
have not checked) that would return true for Hebrew month 6. If that is the 
case, then I would agree we should probably require that behavior for 
RSCALE.

What do others think? Should we change section 4.1 to state that "L" is 
always added to the leap month even in the Hebrew case?

> RRULE:RSCALE=GREGORIAN;SKIP=FORWARD;FREQ=YEARLY;UNTIL=20140301T115959Z

Yes, one "side-effect" of RSCALE is that it does address the problem of how 
to deal with the Gregorian leap day by providing the skip option. Adding an 
example of that in section 4.2.

That said, the current description of SKIP in Section 4 (list item 4) only 
refers to skipping leap months. In addition to the Gregorian leap day, 
there are other kinds of skips that occur - e.g., a monthly recurrence on 
January 31st (as currently defined by 5545) should only occur in months 
with 31 days - the others should be skipped. Should SKIP apply to that as 
well? It may not be necessary in all cases (e.g. the January 31st example 
is likely meant to be "last day of the month" which can be encoded 
precisely in RRULE - but if the intent was "the 31st or the 1st of the next 
month" then skip would be handy).

-- 
Cyrus Daboo

---

From: Ken Murchison <[email-masked]>
Date: Mon, 14 Apr 2014 17:00:52 -0400

Hi Cyrus,

On 04/14/2014 12:03 PM, Cyrus Daboo wrote:
> In most calendar systems with a leap month, months are counted 1 
> through 12, with the leap month being tagged with the "L" suffix where 
> it appears during the year. In the Hebrew calendar implementation in 
> the unicode ICU library, the months are actually numbered 1 through 
> 13. In non-leap years, month number 6 is simply skipped. That is 
> already described in section 4.1 of the current draft.
>
> Now, I suspect from an implementation standpoint, one might want to 
> use isLeapYear(N) as the trigger for adding the "L" suffix and I 
> suspect (but have not checked) that would return true for Hebrew month 
> 6. If that is the case, then I would agree we should probably require 
> that behavior for RSCALE.
>
> What do others think? Should we change section 4.1 to state that "L" 
> is always added to the leap month even in the Hebrew case?

I just ran a quick test using ICU within libical, and it doesn't appear 
to set the IS_LEAP_MONTH flag for the Hebrew calendar for month 6.  I 
haven't tried it with other calendars (i.e. Chinese) to see if its 
cal-specific.

In any case, it would seem to me that the fact that ICU numbers the 
months 1-13 is an internal implementation detail.  How is the generator 
of the iCalendar data supposed to know how the receiver numbers its 
months?  Or am I completely missing the point of "L"?

> Yes, one "side-effect" of RSCALE is that it does address the problem 
> of how to deal with the Gregorian leap day by providing the skip 
> option. Adding an example of that in section 4.2.
>
> That said, the current description of SKIP in Section 4 (list item 4) 
> only refers to skipping leap months. In addition to the Gregorian leap 
> day, there are other kinds of skips that occur - e.g., a monthly 
> recurrence on January 31st (as currently defined by 5545) should only 
> occur in months with 31 days - the others should be skipped. Should 
> SKIP apply to that as well? It may not be necessary in all cases (e.g. 
> the January 31st example is likely meant to be "last day of the month" 
> which can be encoded precisely in RRULE - but if the intent was "the 
> 31st or the 1st of the next month" then skip would be handy).
>

Hmm.  My thoughts are that SKIP should only apply to leap months and 
possibly leap days.  I'm not sure we want to venture any further than 
that.  I would think that 5545 should have handled the other cases already.

---

From: Gregory Yakushev <[email-masked]>
Date: Wed, 16 Apr 2014 20:27:52 +0000

Some thoughts are inlined below. Adding Mark Davis for ICU perspective on
Hebrew leap month implementation.

> months?  Or am I completely missing the point of "L"?
We initially decided for the implementation to be calendaring system
agnostic. We delegate all the logic to ICU, and don't make any
special-casing for various calendaring systems. Such an approach has some
advantages:
1. Any RSCALE implementation will support new RSCALES naturally as they
become available in ICU
2. Any client using ICU for other calendaring arithmetics or localisation
does not need any special-casing either: ICU will localize month 6 as Adar
II, and non-leap. Otherwise clients would have to 'undo' our special-casing.
3. I know there's internal discussion among ICU developers on this issue.
They may opt for introducing another calendaring system (HEBREW2 or
something like that) which will treat leap month differently. If that will
happen - RSCALE implementations will support it natively without any
modification.

The disadvantage is that we essentially tie RSCALE implementation to ICU
implementation. Personally I prefer it this way because it makes life
easier for the clients, but I see that its a debatable choice.

> that.  I would think that 5545 should have handled the other cases already.

The support for Feb 29th and Jan 31st comes naturally from
calendaring-system agnostic implementation. I'd prefer not to add a special
case just to remove some functionality. We can point out that instead of
specifying RSCALE=GREGORIAN;BYDAY=31;SKIP=BACKWARD clients may specify
BYDAY=-1 and get compatibility advantage with non-RSCALE implementations. I
still think that if everybody supports RSCALE, the former syntax is cleaner
and works better for BYDAY=30.

> _______________________________________________
> calsify mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/calsify
>

---

From: Ken Murchison <[email-masked]>
Date: Thu, 24 Apr 2014 10:13:59 -0400

On 04/14/2014 12:03 PM, Cyrus Daboo wrote:
> only refers to skipping leap months.

I'd be fine if SKIP only dealt with leap months, but the fact that the 
comment under the definition of SKIP states that that SKIP defaults to 
YES when RSCALE is not present, leads me to believe that SKIP was at one 
point thought to be used with outside of RSCALE. Perhaps this is 
leftover from an earlier revision of the spec.

---

From: Gregory Yakushev <[email-masked]>
Date: Thu, 24 Apr 2014 15:22:55 +0000

It just references what the current, pre-RSCALE specification does. I.e.
BYDAY=30 is identical to RSCALE=GREGORIAN;BYDAY=30;SKIP=YES. Maybe we
should phrase it differently?

---

From: Ken Murchison <[email-masked]>
Date: Thu, 24 Apr 2014 11:28:08 -0400

Since the text of section 4 says that the SKIP, "L", etc changes only 
occur in the presence of RSCALE, I don't think we need a default for 
SKIP without RSCALE.  SKIP should be ignored (or cause an error) unless 
RSCALE is present.

On 04/24/2014 11:22 AM, Gregory Yakushev wrote:
> It just references what the current, pre-RSCALE specification does. 
> I.e. BYDAY=30 is identical to RSCALE=GREGORIAN;BYDAY=30;SKIP=YES. 
> Maybe we should phrase it differently?
>
> On Thu Apr 24 2014 at 4:14:18 PM, Ken Murchison <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     > <[email-masked] <mailto:[email-masked]>> wrote:
>     >
>     >
>     >
>     [email-masked] <mailto:[email-masked]>

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 24 Apr 2014 11:38:29 -0400

Hi Ken,

--On April 24, 2014 at 10:13:59 AM -0400 Ken Murchison 
<[email-masked]> wrote:

> point thought to be used with outside of RSCALE. Perhaps this is leftover
> from an earlier revision of the spec.
>

I think that comment is wrong. Here is a proposed change:

   skip            = ("YES" / "BACKWARD" / "FORWARD")
                    ; Optional, with default value "BACKWARD",
                    ; and MUST only appear if "RSCALE" is present.

-- 
Cyrus Daboo

---

From: Ken Murchison <[email-masked]>
Date: Thu, 24 Apr 2014 12:22:41 -0400

>                    ; and MUST only appear if "RSCALE" is present.

Work for me.

---

From: Ken Murchison <[email-masked]>
Date: Tue, 29 Apr 2014 12:23:20 -0400

Hi Cyrus,

After just about completing an RSCALE implementation in libical using 
ICU, I'm more convinced that we shouldn't be exposing ICU warts 
<http://cldr.unicode.org/development/development-process/design-proposals/chinese-calendar-support#TOC-C.-ICU-behavior> 
in the RSCALE spec.  The fact that ICU treats leap months in the Hebrew 
calendar different from the Chinese calendar is unfortunate 
<http://cldr.unicode.org/development/development-process/design-proposals/chinese-calendar-support#TOC-D.-Problems-with-the-current-ICU-behavior:>, 
but that fact should be handled by the implementation using ICU, not the 
RSCALE spec where the ICU idiosyncrasies get forced on other 
non-ICU-based implementations.

So, I'm proposing that the leap month in the Hebrew calendar be 6L (or 
even 5L) in RSCALE with the last month being 12 (not 13).  Month 13 
should only be used in RSCALE for calendars that have 13-month non-leap 
years (Coptic, Ethiopic).

Implementations based in ICU already have to translate month numbers 
from being 1-based in iCalendar to 0-based in ICU, so tweaking the 
translation for the Hebrew calendar shouldn't be a problem: 1-5 -> 0-4, 
6L -> 5, 6-12 -> 6-12.