Re: different calendar systems - i18n

On Wednesday, September 17, 2003, at 01:34  PM, Doug Royer wrote:

> I do not think there has been any serious discussions of non gregorian 
> calendars.
> If the 'CALSCALE' were 'jalali' then would not yearly in a recurrence 
> rule work?

I think the point is that right now there's no way to convey a 
recurring non-gregorian date in a way that the recurrence can be 
reconstituted by another calendar system that processes the ical data 
-- right now, the translation has to happen at the point of origin, so 
the best you can do is generate N different events for the next N 
years.  This makes it impossible, for example, for me to configure most 
calendar systems to remind me, in perpetuity, about my mother's 
Yahrtzeit (the Jewish observance of the anniversary of a death).  There 
are even services that have arisen to fill the gap 
(http://yizkor.ort.org)

>> I wonder about the possibility of adding support for jalali(persian), 
>> hijri(islamic), indian civil and hebrew calendar systems (if i missed 
>> one which is still in use it should be added to the list).

When we built a calendar system as part of the Andrew project in the 
mid-80's, Craig Everhart built a core engine that handled multiple 
calendar systems, including the Ecclesiastical Roman calendar.  That 
should be on anyone's top ten list, I think.  And personally, I'd like 
to be able to represent historical events using Julian rather than 
Gregorian dates, but I'll concede that the market demand for scheduling 
pre-18th century events is probably pretty low.

What really matters is that the architecture be extensible.  In 
particular, at this point, the only proper question to ask about ical 
and non-gregorian dates is simply how easily we can extend it in the 
future to support multiple calendars.  I would hate to see any of the 
current documents delayed for that feature, but it wouldn't hurt to see 
if there's a general consensus on how such an extension might work.  Is 
the combination of VERSION and CALSCALE in RFC 2445 and CAP-VERSION in 
the current draft sufficient for such extensions?  I don't see why not, 
but then I'm still new to this stuff...  --- Nathaniel