Re: [calsify] SKIP was Re: AD review of draft-ietf-calext-rscale-03

[Barry Leiba <[e-mail]>]

Yes, so this is starting to show the complexity of trying to have
general rules that one can apply, rather than "just knowing" how each
calendar works -- that is, saying that the behaviour is specific to
each calendar, and you have to know, when you implement a calendar,
how that calendar works.

In fact, you do: you have to know it in order to know how to generate
the correct SKIP entries.  So why don't we just say that you have to
know it on both ends, and in most cases SKIP won't be used (it's only
to make exceptions from the normal case)?

Maybe that means we should have a registry for calendars and their
SKIP behaviour, where we could put in at least the common calendars we
expect to see used -- there can't be that many.  Or... or maybe we
just say that if you're going to support a calendar, you have to do
the research and know how that calendar works in practice.

Does that latter mean that we might get bad implementations that don't
do it right?  Sure.  But with SKIP as we're doing it, we also might
get bad implementation that don't generate the SKIP(s) right.

Barry

On Tue, Feb 3, 2015 at 10:08 AM, Cyrus Daboo <[e-mail]> wrote:
> Hi Ken,
>
> --On February 3, 2015 at 10:02:01 AM -0500 Ken Murchison
> <[e-mail]> wrote:
>
>> It appears your previous rules properly handle the 30 Adar I (leap year)
>> case, but the new rules do not.  Can we come up with rules that can model
>> the 3 cases listed above?
>
>
> OK thanks for looking into that. If we want to provide full flexibility to
> control what happens we would need to have two "skip" indicators, one for
> skipping invalid months and one for skipping invalid days (with the month
> one applied first, followed by the day one). So:
>
> RRULE:FREQ=YEARLY;SKIP-MONTH=FORWARD;SKIP-DAY=FORWARD
>
> Would match the Hebrew birthday case you found.
>
> RRULE:FREQ=YEARLY;SKIP-MONTH=FORWARD;SKIP-DAY=BACKWARD
>
> Would match the behavior from my last email. If we find there really is
> never a use case for the above, then we could stick with the single SKIP
> option. But lets see if we can get a confirmation on that.
>
> --
> Cyrus Daboo
>