Re: different calendar scales

[email protected]
Newsgroups gmane.ietf.calendar
Message-ID <OF0D20803B.6AE324CB-ON85256DD4.00556E44-85256DD4.00573BDB@notesdev.ibm.com>
John replied on 11/03/2003 04:17:52 PM:
> I think, if we ever get non-Gregorian scales, we'll have to mandate that 

> all iCalendar implementations support Gregorian, for interop with 
> existing implementations. 

That defeats the purpose of having CALSCALE in the entity doesnt it?  The 
reason that CALSCALE exists was so that going forward ANY CUA who does the 
right thing and checks for CALSCALE first will be able to fail in a 
graceful way instead of accidentally running amok off in the weeds.  Well 
behaved iCalendar implementations SHOULD be checking CALSCALE first and if 
its there, making sure it is one they grok before trying to deal with any 
time/date values on ANY property, not just recurrences. 

Its better to put up a dialog with "This iCalendar is based on the 
'MiddleEarth' calendar scale which I do not understand.  I am unable to 
properly open and display it.  Do you want me to notify the sender of this 
or just toss it in the trash?" than try to unwind recurrence rules that 
will appear malformed or invalid and put cruft on the users calendar (or 
crash in doing parsing attempts or...).

More practically, if you ignore the CALSCALE:HEBREW and treat the RDATEs 
as GREGORIAN date/time values you could be in a world of hirt.  For 
example, 15-Dec-1998 (GREGORIAN; 19981215) is 26-Kislev-5759 (Hebrew; 
Maybe 57590326 in ISO-9601 notation).  If an older iCalendar client 
ignored CALSCALE they could misparse it and put an entry on the users 
calendar for ~3700 years in the future instead of ~5 years ago.

Also, you need to factor in that not all data is going to be CAP sourced. 
It may arrive via iMIP or some other means.

>                          But there really isn't any good solution for 
> that; people who want to schedule events based on phase of the moon will 

> not be able to do so when communicating with people whose CUs don't 
> support it.

Thats why we never said all C&S MUST be in GREGORIAN calendar scale and 
why we invented the CALSCALE property.

So do you think adding calscale to the GET-CAPABILITY response is a good 
or bad thing??  I even provided sample text and ABNF for Doug to use if 
the group thinks its a smart thing to do.

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...
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.