Re: Personal Calendar Server Volunteer? (fwd)

[Miles Lane <miles amazon com>]

Interesting.

Another calendar I know is the one used by members of 
the Baha'i Faith.  It is a solar calendar comprised
of nineteen months with nineteen days each (361 days).  
To adjust the calendar to the solar year, four Intercalary 
Days are added (five in leap years) between the eighteenth 
and nineteenth months.  The Bahá'í New Year, Naw-Rúz, is 
astronomically fixed, commencing at the March equinox (usually 
March 21st), and the Bahá'í era commences with the year of 
the Báb's Declaration (i.e. 1844 A.D.).  Also, in this system, 
there another interesting difference.  Specifically, the new 
day begins at sunset, not at midnight.  Lastly, the are four 
or five "intercalary days" (five on leap years) which round 
out the year to 365.

Cheers,
	Miles

Russell Steinthal wrote:
> 
> Ali,
> 
> The idea of integrating lunar calendar support into
> gnomecal/Evolution is interesting, and one I've given some thought to
> in the past, but in a slightly different context.  One of the
> projects which has sat in a perpetually unfinished (and unworked on,
> frankly) state on my computer has been a Hebrew Calendar program,
> which would also be lunar-based; I've never given any *serious*
> thought to integrating it into gnomecal, however, beyond possibly a
> CORBA interface to mark Jewish holidays, for example, in my gnomecal.
> 
> That being said, I am reasonably familiar with the issues involved in
> such a calendar implementation, so here are my thoughts:
> 
> On Thu, 03 Feb 2000 16:34:45 +0300, Ali Abdin wrote:
> 
> >Anyway, I was also thinking a bit about this and realized that the
> >'native' date/time format on Linux/Unix is Gregorian based. Would it
> be
> >'feasible' to implement a low-level Linux/Unix solution first or
> should
> >the Lunar Calendar be based on some sort of 'conversion' from the
> date in
> >Linux/Unix. Hmmm, come to think of it - doesn't the Linux/Unix date
> just
> >return a 'seconds elapsed' since 1979 or something like that?
> 
> Building a kernel-level infrastructure is simply not worth the
> trouble, IMHO.  The PC clock counts (fractions of) seconds, which is
> what time_t stores (seconds since the epoch).  The infrastructure is
> Gregorian to the extent that libc has code for time_t to Gregorian
> conversions (localtime, etc.).  If you thought there was a
> general-purpose need for Islamic time calculations, you could, I
> suppose submit patches to glibc, but I think that for most purposes a
> separate library would be fine.  (I wonder if the glibc locale
> support is general-purpose enough to handle a different calendar
> system, rather than simply a different format?  Just curious...)
> 
> A related problem, though, is that there is no such thing as a single
> "lunar" calendar.  The Islamic calendar, for example, differs from
> the Hebrew calendar. (The Hebrew calendar, for example, is actually
> lunar/solar, in the sense that there's an intricate system of leap
> months used to keep the lunar months from floating through the
> seasons.)  So any solution you build should be sufficiently modular
> to allow any number of different calendar systems.
> 
> >Since the major effort is all going into evolution, I wanted to
> 'explore'
> >that possibility. Specifically, I was interested on what is required
> for
> >lunar calendar support for Evolution. I come from a culture (Arab)
> that
> >uses the Lunar Calendar, so I am pretty experienced with it (there
> are
> >some Lunar Calendar quirks since one month can be either 29/30 days
> >depending on Moon Sighting). I believe this is just in the "Islamic"
> >calendar (which is lunar based). Enough rambling.
> 
> What would be required?  Offhand, here's what I came up with:
> 
> 1. A library to handle conversions from an arbitrary time_t to a
> "lunar" date/time.  (Subject to the vagaries of the multiple calendar
> point I mentioned above.)
> 
> 2. Modified versions of the calendar widgets used in gnomecal which
> don't contain Gregorian assumptions like the number of months, the
> number of days per month, month names, etc.
> 
> 3. If you want to make this a native format, you need code to handle
> loading and saving.  Interestingly, the iCalendar specification
> implicitly supports multiple calendar systems- that is, there's a
> CALSCALE property which can theoretically designate the calendar
> format in use for that file.  As the RFC says, however:
> 
>    This memo is based on the Gregorian calendar scale. The
>    Gregorian calendar scale is assumed if this property is not
> specified
>    in the iCalendar object. It is expected that other calendar scales
>    will be defined in other specifications or by future versions of
> this
>    memo.
> 
> In theory, at least, all the rest of gnomecal should function as
> before, since internally, we use time_t + TIMEZONE (or at least we
> soon will; right now, timezone support is a bit shaky).
> 
> Figuring out how to handle the moon-sighting issue is also a hairy problem, but I'll leave that to you as an exercise. :)  (The Hebrew calendar, at least, is algorithmically-generated.)
> 
> -Russell
> 
> --
>         FAQ: Frequently-Asked Questions at http://www.gnome.org/gnomefaq
>          To unsubscribe: mail calendar-list-request@gnome.org with
>                        "unsubscribe" as the Subject.