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

Hi Rich,

--On September 7, 2010 2:45:36 PM +0200 Rich Tibbett 
<rich.tibbett@gmail.com> wrote:

> I'd like to request that we cancel the 'recurring lunisolar events'
> conference call based on the lack of workable solutions that have been
> presented thus far in W3C DAP and also due to the general lack of
> interest shown in the Doodle poll for the proposed conference call. 

An email discussion (as you have just started) is a good starting point 
here.

> My main concern is whether we have a real issue here at all or whether
> the current approach is in fact the best approach for supporting
> internationalized dates.
>
>
> The problem is well understood and yet there are no practical proposals
> on the table other than the current approach: to choose a single
> calendaring storage format (Gregorian) and then to apply calendar
> conversion mechanisms on any input and output data as required.

That is only feasible for "static" dates. But in reality a lot of dates 
that people want to represent are recurring - anniversaries, holidays, 
religious festivals etc. The iCalendar data format does define recurrence 
rules for the Gregorian calendar scale (the only one it currently supports) 
but those cannot be correctly applied to other calendar scales (in the 
general case).

So if recurrence rules are a requirement for non-Gregorian calendars, then 
we will have to work on new calendar scales for iCalendar and define new 
ways to represent those.

It is worth noting here that iCalendar has both recurrence rules (RRULE 
property) and recurrence dates (RDATE property). The later represent a 
finite set of specific date-times for recurring instances of a "master" 
event. RRULE can represent unbounded recurrence or finite recurrences (by 
limiting them with a COUNT or UNTIL option). Now a set of bounded 
recurrences can always be mapped from one calendar system to another (as 
you note), and whilst that may seem sufficient, ultimately it may not be. 
If there really is a rule controlling the instances it is better that that 
rule be properly encoded in the event so that if additional instances do 
need to be added it is clear what they will be.

> The ability to convert between different formats is possible
> independently of the API and/or its storage of data. If a 3rd-party
> library can convert to and from gregorian<->lunar dates then we can say
> that the API supports lunisolar events and recurring lunisolar events by
> proxy (in the sense that Gregorian dates can be converted to Lunar dates
> by the said library and vice versa).
>
>
> It is a paradox to say that sticking with one format is the best way of
> supporting internationalized dates but I believe that is the most
> workable solution here.
>
>
> If others have different opinions then I would like to see practical
> workable proposals before getting in to a conference call. I'm unsure
> there are other proposals that will work quite so well.
>

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.

-- 
Cyrus Daboo

Received on Tuesday, 7 September 2010 14:06:01 UTC