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

[Marten Gajda <[e-mail]>]

Am 04.02.2015 um 12:26 schrieb Gregory Yakushev:
> Quite a discussion here, let me try to catch up.
>
> As for 
> FREQ=YEARLY;RSCALE=HEBREW;MONTHLY=5L;BYDAY=MO,TU,WE,TH,FR,SA,SU;SKIP=FORWARD 
> case, its clearly artificial and doesn't represent any real-world 
> usecase, so there's no preference for our users on how to handle it.
That's true, but it's probably easy to generate a real world example 
where the execution order of SKIP and BYxxx rules matters.

The question is, do we want BYDAY and BYMONTHDAY expansion to be 
executed on the days of the skipped leap month or on the days of the 
actual month?

The more I think about this, the more I like the idea to apply SKIP 
right after BYMONTH when skipping a leap month. When you expand BYDAY=SU 
for a leap month you probably want to expand all Sundays in the 
following (or preceding) month when the year is not a leap year. The 
number of Sundays you expand for the skipped month might be different 
from the number of Sundays in the next or previous month. Also when 
rolling a day backwards to the previous month, a Sunday would fall on a 
different weekday (unless the number of days in that month is a multiple 
of 7).

>
> As was cleared above, SKIP behavior is clear for all Calendars except 
> Hebrew, and for all except Hebrew people will use SKIP=BACKWARD for 
> most usecases.
>
> It is important to clear the Hebrew case, but lets keep in mind this 
> we are talking about a very narrow usecase for a relatively small 
> number of users. It will be unfair to complicate life for billions of 
> Chinese or Hindu users to make Hebrew case perfectly right.
I think the user shouldn't notice any difference. It's the developers 
that have to get this right. Setting the default to SKIP=OMIT sounds 
like the best solution to me. It doesn't prefer any specific calendar 
and it doesn't change the semantics of existing rule when you add 
RSCALE=GREGORIAN but no SKIP.

Marten

>
> Do I understand correctly that current draft allows to specify an 
> RRULE for all Hebrew cases, even though it looks ugly for Adar I 30th?
>
> Grisha
>
>
> On Tue Feb 03 2015 at 10:50:15 PM Marten Gajda <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>
>     Am 03.02.2015 um 22:04 schrieb Cyrus Daboo:
>>     I think Ken's idea is that you apply the SKIP after BYMONTH only
>>     if the invalid data corresponds to an invalid leap month as
>>     opposed to a leap day. In which case the SKIP would not have
>>     applied after BYMONTH in your example. But I think a behavior
>>     like that is going to be really tricky for implementors to get
>>     right and hard to describe really well without having to delve
>>     into the gory details of RRULE processing.
>>
>     Ah, got it.
>
>     So, considering the following
>
>     Applying SKIP=FORWARD after BYDAY on the following rule
>
>     FREQ=YEARLY;RSCALE=HEBREW;MONTHLY=5L;BYDAY=MO,TU,WE,TH,FR,SA,SU;SKIP=FORWARD
>
>     results in 30 instances in leap years and in non-leap years, since
>     it would expand the week days in Adar I and roll them forward
>     afterwards
>
>     Applying SKIP=FORWARD after BYMONTH but before BYDAY results in 30
>     instances in leap years, but 29 instances in non-leap years, since
>     the weekdays would be expanded for Adar instead of Adar I.
>
>     It's similar when the month following the leap month has more days
>     than the leap month itself.
>
>     In essence, applying SKIP after all BYxxx parts won't change the
>     number of instances (given they don't fall on another instance),
>     but Ken's approach might do that.
>
>     Not sure what's preferable in this case.
>
>
>
>
>     -- 
>
>     *Marten Gajda*
>     Schandauer Straße 34
>     01309 Dresden
>     Germany
>
>     tel: [phone]
>     email: [e-mail] <mailto:[e-mail]>
>     twitter: twitter.com/dmfs_org <http://twitter.com/dmfs_org>
>
>     VAT Reg. No.: DE269072391
>
>     _______________________________________________
>     calsify mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/calsify
>


-- 
Marten Gajda
Schandauer Straße 34
01309 Dresden
Germany

tel: [phone]
email: [e-mail]
twitter: twitter.com/dmfs_org

VAT Reg. No.: DE269072391