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

[Gregory Yakushev <[e-mail]>]

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

On Mon Apr 14 2014 at 11:01:38 PM, Ken Murchison <[e-mail]>
wrote:

> Hi Cyrus,
>
>
>
> On 04/14/2014 12:03 PM, Cyrus Daboo wrote:
> > Hi Ken,
> >
> > --On April 11, 2014 at 12:44:21 PM -0400 Ken Murchison
> > <[e-mail]> wrote:
> >
> >> 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.
> >
> > 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"?
>
>
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.

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

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.


>
> --
> Kenneth Murchison
> Principal Systems Software Engineer
> Carnegie Mellon University
>
> _______________________________________________
> calsify mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/calsify
>