W3C home > Mailing lists > Public > www-rdf-calendar@w3.org > December 2002

Re: non-gregorian calendars [was: ical schema...]

From: Charles McCathieNevile <charles@w3.org>
Date: Sat, 21 Dec 2002 18:06:29 -0500 (EST)
To: Dan Connolly <connolly@w3.org>
cc: <www-rdf-calendar@w3.org>
Message-ID: <Pine.LNX.4.30.0212211724410.14312-100000@tux.w3.org>

On 21 Dec 2002, Dan Connolly wrote:

>On Fri, 2002-12-20 at 23:28, Charles McCathieNevile wrote:
>> Planning according to menstrual cycle. This is something that real people do.
>> Often these will follow a lunar calendar, in which case an islamic calendar
>> works, or they will be regulated on a strict cycle of 28 days.
>A 28 day month sure makes a lot more sense; the story I heard was that pope
>gregory thought 13 months in the year was too pagan or something so he had
>to deploy something different. And the rest, as they say, is history.

History is more or less bunk (speaking as a trained historian). Actually the
problem (according to my version of history) was that people disagreed about
when Easter was, because the 12-month Calendar introduced by Julis Caesar
following a year of 400-odd days was slightly misaligned with the solar
calendar it was supposed to match, and which was crucial for determining

In our terms there were two standards required to find Easter (the most
important christian festival, and therefore a vitally important calculation
at the time, since people did things like calling truces in war) and they
didn't interoperate properly.

>Frequently Asked Questions about Calendars
>Version 2.4 Claus Tøndering 28 October 2001
>Perhaps something to link from the calendaring workspace... bonus points if
>you beat me to it.
(Well; I discovered I had been beaten to the bonus points :)

>> Finding Easter. For non-orthodox churches (which is my own use case, and
>> therefore the one I am most familiar with) I believe this can be readily
>> determined with only a lunar calendar, a solar calendar, and a jewish
>> calendar (I need to know the first full moon after the equinox, and then
>> whether or not pasoch falls on that date).
>A practical implementation strategy for this sort of thing...
>I gather these things often actually depend on astronomical observation,
>in which case there's no hope of computing them locally without
>doing some I/O. And if you're going to do I/O, you might as well
>do an HTTP GET to some trusted source that maps "the next easter"
>to a gregorian YYYY-MM-DD. This is the same approach
>I use to map city names and airport codes to lat/long;
>  http://www.w3.org/2000/04/mem-news/teamToGlobe

These things tend to be calculated (Easter had, and Ramadan has, a massive
impact on an international scale, so calculating it in advance is considered
an incredibly important practical application of predicting astronomical
phenomena). Ramadan is a month in the lunar calendar it is part of, and while
that depends in principle on when the moon can be seen it is important to
know even if the sky is cloudy.

Which still doesn't mean that it is a bad idea to do a GET for it, using some
kind of service. (Bonus points for me if I build a converter for Ramadan,
since that was what I wanted to know and it is probably already out there,
and could be a good driver for adoption of this stuff).

The question was whather it makes sense to have deeply semantic calendar
names, or whether there are so few of hese in practice that strings are fine.

I would prefer to have URIs - in particular that makes it easy to reliably
state that my Ramadan converter (I would probably do better to just have a
muslim calendar service that interoperated) produces things for the Gregorian
calendar, and not for a putative new version of it that takes into account
the slowing of the earth's rotation and the decay of its orbit, nor is it
directly useful for comparing events in history dated according to the
"english usage" or the October revolution (which took place in what english
speakers called november).


Received on Saturday, 21 December 2002 18:06:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:14:11 UTC