Re: different calendar systems - i18n

On Friday, September 19, 2003, at 08:48  PM, Doug Royer wrote:

> 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?

The point is simply that "yearly" won't work if the calendar data is 
passed off to a calendar server that doesn't understand the calendar 
type (CALSCALE) in the first place.  This underscores the need to make 
sure the extensibility is "done right."  (This is a sore point with me, 
since we defined "MIME-Version" so badly that there will probably never 
be anything but 1.0.)

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

This, on the other hand, is what I'm afraid of -- I want to make sure 
we *know* how such extensions should

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

No dispute there, only the question (posed to the list as a whole):  
Does everyone agree that the current extension mechanisms (VERSION, 
CALSCALE, CAP-VERSION) suffice to ensure that the desired extensions 
can be done correctly, i.e. without ever creating situations like the 
one I describe above, in which an older server accepts calendar data 
that it really doesn't know how to handle because of the unsupported 
CALSCALE.  My guess/hope is that the answer is yes, but I would feel 
better knowing that wiser heads than mine have thought seriously about 
the problem and come to the same conclusion.  -- Nathaniel