Re: different calendar systems - i18n

Doug wrote on 09/19/2003 08:48:31 PM:
> I got the point and I agree. I know nothing about 'Yahrtzeit' or a 
> Jewish calendar.
> 
> If a 'jalali' RFC were published with the rules and given that fact that 

> 'YEARLY' is NOT defined to mean
> every 365 days. Why would not 'YEARY' in a 'jalali' calendar, do the 
> correct 'jalali' math
> to produce the correct dates? Or are you saying that YEARLY (or 
> whatever) will not ever work?

There are other GREGORIAN 'biases' in the current Recurrence Rule we have 
in iCalendar.  Stuff like the days in the month, the number of months in 
the year, the weekday _names_, etc.  As such its not a simple matter to 
just define another CALSCALE property value and be done with it.

To support non-Gregorian calendars, iCalendar needs to have changes 
besides the new token for CALSCALE.  It can be done using the current 
properties without any radical changes (ie: new properties, etc).  The 
current properties can be reused but their property values (or 
'sub-values' in the case of the grammars) need to be changed.

I would also hope that noone blindly ignored checking CALSCALE, if its in 
the iCalendar stream, and just plows ahead with item evaluation...  If 
they do, oh well they get what they get then...

> Or  if needed, you could define a J-RECUR data type to solve the 
problem.

No need to define new properties that define the same function as existing 
properties but with slightly different data points (ie: weekday 
names/designations).  That would be wasteful and needless really.  Any new 
calendar scale draft should take the time to properly refine the 
recurrence/exclusion rules and related data items so that we dont get 
bloating or dupliation of semantics (ie: a new repeat rule property for 
each CALSCALE type is dumb IMNHO).

> And my point was - if needed submit a draft, publish the results, and 
> keep working at it until
> and RFC is published.

I think we all agree here.  The only question that remains unanswered is 
does CAP need to be changed to address this? 

For example, just how would a CUA detect if a CS supports CALSCALEs other 
than GREGORIAN short of doing 'probes' of some kind?  Or does CAP need to 
care at this point since there are no other CALSCALEs even in draft at 
this point? 

We may not really care and since the "default" is GREGORIAN so no 
"CALSCALE" capability means essentially "only Gregorian spoken here"... 
For later CAP drafts, as new calendars are defined, we may need this but 
for now do we?  (Will leaving it out be a problem later on?...)

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email protected]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...