Subject: [Ietf-calsify] B.C.E and Y10K problem with iCalendar?

From: tomasek at etf.cuni.cz (Petr Tomasek)
Date: Sun Mar 25 05:40:12 2007

Hello!

(I hope this is the right mailinglist and my quostion
isn't disturbing here anyone.  Also, I'm not english
native-speaker, so, please, sorry for my formulations).

I'd like to ask, why doesn't the iCalendar allow
for dates B.C.E and/or where abs(Year)>9999?

As far as I understand (according to the latest draft)
the year (in DTSTART and DTEND) must in 4-digits
format although the ISO 8601 would allow for extended
representation (ISO 8601:2004, 4.1.2.4).

For the iCalendar, being general format for calendar information it
would make sense to use it e.g. for informations about
historical events (consider for example a timeline application
that would be able to download sources from various webpages,
just like today's calendar apps do with "webcal" calendars...)

So my quoestion is: wouldn't it be possible to extend (in some
future version of the standard) the format of iCalendar to
support?

Thanks!
Petr Tomasek

-- 
Petr Tomasek <http://www.etf.cuni.cz/~tomasek>

---

From: lear at cisco.com (Eliot Lear)
Date: Sun Mar 25 09:22:52 2007

<chair hat off>

Petr,

Thanks for your email.  To your first point about BCE, while I 
understand the desire to develop perhaps calendars of timelines, I am 
afraid that it is difficult enough to get calendaring to interoperate 
for events in this year, no less this century.  Regarding dates greater 
than 9999, if man survives that long I would hope that someone could 
revise the standard, some years prior to that time (like maybe in 
9990).  I am concerned that making a change to the date format would 
cause massive interoperability problems, requiring a version bump, which 
itself would cause problems.  However, if you believe there is a need 
for such a calendar, perhaps it would be worth investigating an 
experimental version.

And so on a related topic, I believe we should make it clear to 
implementors that they ignore VERSION at their peril.

Warmest regards,

Eliot

---

From: MRC at CAC.Washington.EDU (Mark Crispin)
Date: Sun Mar 25 10:19:21 2007

Leaving aside the small matter that there was no year 0, BCE predates the 
current calendar by several centuries.  Due to the complexity of the 
conversions between contemporary calendars and the modern calendar, any 
reported dates in that timeline need to be taken with a grain of salt.

Long before we get to Y10K, matters will come up that will necessitate the 
modification of the modern calendar.  At around Y3.3K, the modern calendar 
goes slow by a day.  Current thinking is to make Y4K and other years 
evenly divisible by 4000 not be leap years; however this will only patch 
things up until about Y20K.

The Eastern Orthodox church has its own modifications to the modern 
calendar; in their calendar, century years module 900 must result in a 
value of 200 or 600 to be considered leap years.  This makes a difference 
starting in 2800, where the two diverge until 2900; and again between 3200 
and 3300; and then at increasing intervals.  Although more accurate, the 
Eastern Orthodox calendar falls apart at about Y43K.

On top of that, there are perturbances in the Earth's rotation and orbit 
that none of these systems handle, including some that we don't know about 
yet.

Last but not least, there is quite a debate between those who advocate the 
UTC continue in the spirit of the old GMT (adjust the time with leap 
seconds as needed so that 12:00:00 UTC represents noon at 0 degrees 
longitude); and those who want a timebase that follows makes it easy to do 
arithmetic between times.  Most people ignore leap seconds entirely, a 
rational position given that their clocks have much greater drift than a 
leap second.  That is not an option for people in the precise timing 
community.

If you want to read more, look at:
 	http://staff.washington.edu/mrc/calendar.html

The bottom line is that any attempt to represent BCE or far future dates 
in a calendaring system based upon our current calendar is doomed to 
failure.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

---

From: tomasek at etf.cuni.cz (Petr Tomasek)
Date: Sun Mar 25 21:14:27 2007

> reported dates in that timeline need to be taken with a grain of salt.

I agree, but there may be need to actualy represent such dates in
iCalendar even if their exact distance from today's date may
not be accurate/sure (I mentioned the idea of some sort of timeline application
that could use iCalendar for storing historical events).

> modification of the modern calendar.  At around Y3.3K, the modern calendar 

Well, I was thinking more of "Y10K BCE", than about the future ;-).

> in a calendaring system based upon our current calendar is doomed to 

I disagree. Historicians do represent BCE dates in their publications
quite often.

---

From: tomasek at etf.cuni.cz (Petr Tomasek)
Date: Sun Mar 25 21:54:30 2007

On Sun, Mar 25, 2007 at 10:22:08AM -0400, Paul B. Hill wrote:
> Please see section 4.7.1. of RFC 2445:
> 
> ---------------------------------
> 4.7.1 Calendar Scale
> 
>    Property Name: CALSCALE
> 
>    Purpose: This property defines the calendar scale used for the
>    calendar information specified in the iCalendar object.
> 
>    Value Type: TEXT
> 
> .... 
>      CALSCALE:GREGORIAN
> ---------------------

Thank you for pointing that out! It seems to me, that the misconception
of iCalendar is in that it makes possible to use 'CALSCALE', but
the definition of date/date-time format is not bound to the 'CALSCALE'
property.

Consider e.g. if one would use "CALSCALE:JEWISH" in specialized
application (it wouldn't be understood by other apps anyway),
but wouldn't be able to use it in compliance with the RFC,
because the jewish calendar can have 13 months which is not allowed.

So I would propose (for a future version) of iCalendar to:

 a) define what characters date/time can use in general (so that
parsers can validate the document). I would suggest something
like this (in regexp syntax): "[0-9A-Z.+-]+".

 b) state that the date/time format depends on the CALSCALE property
and define it for "CALSCALE:GREGORIAN" exactly like it is defined
today (so it won't break anything for iCalendar files that use
"CALSCALE:GREGORIAN").

 c) perhaps define some other date/time formats (in terms of "client
MAY implement") for "CALSCALE:JULIAN" and "CALSCALE:ASTRONOMIC" (I would
suggest to use here the so-called "Julian date number") where exact
algorithms for converting to/from "CALSCALE:GREGORIAN" would be described.

One may also define something like "CALSCALE:REAL_JULIAN" for dates
before 12 AD where the exact correlation between the julian calendar
and the "astronomic date" is unsure[*].

> However, I am not aware of any implementations of an iCalendar based 
> system that implements a non-gregorian CALSCALE. I assume that this is 
> because there is no market demand.

But anyway, it would be nice, if the iCalendar allowed for iCalendar
with CALSCALE other than GREGORIAN to be used correctly.

Petr Tomasek

[*] See http://en.wikipedia.org/wiki/Julian_calendar#Leap_year_error

---

From: tomasek at etf.cuni.cz (Petr Tomasek)
Date: Sun Mar 25 22:08:33 2007

On Sun, Mar 25, 2007 at 07:21:48PM +0200, Eliot Lear wrote:
> ...
> itself would cause problems.

Well, I didn't want to say, You must change the standard immediately ;).

I'm just trying to find a solution that could be adopted in
some future (major?) version of the standard.

Beside, bounding the date/time format to the CALSCALE
property would seem to me the right way that would IMHO not
cause compatibility probles and would make the standard
more clean/extensible for the future.

> However, if you believe there is a need 

Do You mean investigating how would the change affect existing
implementations?

> implementors that they ignore VERSION at their peril.

Best regards,
Petr Tomasek

---

From: lear at cisco.com (Eliot Lear)
Date: Mon Mar 26 00:09:33 2007

> Do You mean investigating how would the change affect existing

While I personally don't believe that the iCalendar standard will serve 
you well for your purposes, I see nothing wrong with attempting to 
develop either a new timescale or other changes in an experimental way.  
Mark Crispin is correct that there is some difficulty going backwards in 
time with regard to calendaring (past 1970 causes problems).  Those 
problems will be non-trivial.  For adoption as a standard you would 
clearly need to address concerns about existing implementations, and 
those too would likely be non-trivial.