Re: doodle (Re: Scheduling calendaring coordination call.)

Robin Berjon wrote:
> On Sep 7, 2010, at 15:05 , Cyrus Daboo wrote:
>    
>> So having thought about this a little, the following would be needed in iCalendar to support alternative calendar systems:
>>
>> 1) A generalization of the ISO-8601 date-time format subset, as used by iCalendar, to support other calendar scales. At its simplest this probably means relaxing the limits on the month and day values (i.e., some calendar systems have more than 12 months in a year).
>>
>> 2) Change the RRULE property definition to support arbitrary calendar systems. e.g., right now the RRULE property defines some elements that use Gregorian day name abbreviations (SU, MO, TU, WE, TH, FR, SA). So those should be changed to perhaps a numeric or alpha representation with a well-defined mapping to actual day names in each calendar system. With that the current RRULE definition may also be sufficient for use with other calendar systems.
>>
>> Again this all boils down to the question of whether recurrence rules are a requirement for non-Gregorian systems. I think that is the first question that must be answered.
>>      
>
> I believe that they are — the use cases I've heard seem to frequently involve birthdays and holidays.
>    
I believe these two use cases are enough to validate this as a 
requirement for recurring non-Gregorian events.
> But there's also a pragmatic sausage-factory aspect to take into consideration. It seems that properly supporting recurrence in non-Gregorian calendars would require non-trivial changes to iCalendar. We're happy to help, but we're the wrong group to do that. I think this is pointing at an update to iCalendar, which we would mirror in a future revision.
>    
I reflect this opinion. It does defer the onus to IETF but the W3C 
effort here is not to invent new calendaring formats at the expense of 
interoperability with existing formats (iCalendar). We hope this 
discussion and others will be helpful to the groups defining these 
formats and we will provide any and all input that we can to that process.
> I'd like to find a solution that is as I18N-friendly as possible but can be made to work atop iCalendar as deployed today. I'm not at all fluent with calendar modelling, but could we recommend that:
>
>    • in version 1, for non-Gregorian calendars, a long list of RDATE be generated; and
>    
This could certainly work for non-Gregorian usage.

A long list of RDATE is certainly a workable proposal for lunisolar 
recurrence in the first instance, essentially distilling recurring 
events to a finite set of 'static' dates that can be modelled as 
Gregorian dates for storage purposes.

It builds atop of what we currently have in iCalendar but obviously has 
its limitation at X number of recurrences. So what is X? Is it an 
arbitrary implement-dependent or independent value?

A first version like this allows us to build atop of an iCalendar 
compliant design in subsequent versions in sync with iCalendar 
development around this topic.

>    • an X-USER-CALENDAR extension (which we'd define) be included to specify which calendaring system to use when displaying the event?
>    
This could be good, though perhaps a client will just choose to display 
an event based on the current user's locale rather than on the original 
format used to specify the event.

The user has a local calendaring mode, the storage is in Gregorian and 
so we can do conversion (or not) based on that information. At the point 
of displaying the calendaring data the non-Gregorian system used to 
generate the event has already been wiped out (in exchange for X number 
of recurrence representations). The user's locale is important here as 
compared to the originator's calendaring locale for displaying any 
recurrence rules included. So if the user is on a Gregorian system then 
display the event in a Gregorian format. If the user is on a Lunisolar 
system then pass the date information through a convertor and then 
display the event in the Lunisolar format.

- Rich