Subject: different calendar systems - i18n

From: Matthias Laabs <[email-masked]>
Date: Wed, 17 Sep 2003 15:22:52 +0430

Hi,
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).
While you can easily translate a date among these on application side (except 
for hijri) there is an unsolved problem within reccurencies - having an event 
on every newyear's of the jalali calendar is not possible in iCal, neither an 
event on every first day of the month.

I am new to this list and the mail archive lacks a search engine - so i am 
sorry if this topic has been discussed already and i would appreciate a link 
to the discussion.

Please let me know what you think about this issue.

Thanks alot,

greets,
Matthias Laabs

---

From: Doug Royer <[email-masked]>
Date: Wed, 17 Sep 2003 11:34:58 -0600

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 am not an expert on 'jalali' so I would think that the rules would 
have to be discussed and
published (rfc) then it seems to me as if it would work.

-- 

 Doug Royer                     |   http://INET-Consulting.com 
 -------------------------------|-----------------------------
 [email-masked]                 | Office: (208)612-INET
 http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                |   Cell: (208)520-4044

                We Do Standards - You Need Standards

---

From: Nathaniel Borenstein <[email-masked]>
Date: Fri, 19 Sep 2003 20:03:23 -0400

> If the 'CALSCALE' were 'jalali' then would not yearly in a recurrence 

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)

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

---

From: Doug Royer <[email-masked]>
Date: Fri, 19 Sep 2003 18:48:31 -0600

Nathaniel Borenstein wrote:

>> I do not think there has been any serious discussions of non 
>> gregorian calendars.
> 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 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?

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

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

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

--

---

From: Nathaniel Borenstein <[email-masked]>
Date: Sat, 20 Sep 2003 13:32:09 -0400

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

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 

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

> 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

---

From: Doug Royer <[email-masked]>
Date: Sat, 20 Sep 2003 13:08:20 -0600

> the problem and come to the same conclusion.  -- Nathaniel

There is no way that an older server will know how to process new 
extensions. A properly implemented
server would look at CALSCALE, VERSION, ... (and what ever) and know 
that it does not know how to handle it.
If your server gets CALSCALE:foo and it does not know what to do with 
'foo'  then it better send back
an error.

CAP would not care when RECUR-EXPAND is false what the CALSCALE value 
was set to as such a CS
would never be trying to do anything with recurrence rules. If 
RECUR-EXPAND is true, then yes
the CS should reject the data if it does not understand CALSCALE:foo . 
Do you think we need to
say that in CAP?

VERSION is the iCal format version, not the version of the data that it 
contains. So VCARD works
as a valid iCAL data because it conforms to version 2.0 of the iCAL 
format. Such a CS would only
need to add VCARD to its COMPONENT capability list. So I think that 
VERSION will never
be effected by the CALSCALE value as VERSION does not change when new 
components, properties
or parameters are added.

CAP-VERSION is intended to tell the CUA which RFC's the CS supports. It 
would not
imply that CALSCALE:foo is or is not supported.

Do you think that we can say that RFC -XXX (CAP) supports GREGORIAN and only
after a new CALSCALE value is published we could then add a new 
CAPABILITY to CAP
that tells the CS what CALSCALEs the CS supports. Or do you feel we need 
to have
a CALSCALE capability now? Or as CAP-VERSION is a comma separated list
could such a CALSCALE:foo CS just add RFC-foo to its list?

--

---

From: [email-masked]
Date: Mon, 22 Sep 2003 12:02:14 -0400

> 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 

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-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Doug Royer <[email-masked]>
Date: Mon, 22 Sep 2003 10:54:08 -0600

[email-masked] wrote:

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

When someone publishes the details for a new CALSCALE value then the 
debate will have meaning.
Until then everyone seems to be saying  that we can only guess and I agree.

--