Re: Personal Calendar Server Volunteer? (fwd)

[Ali Abdin <aliabdin aucegypt edu>]

Thanks for your feedback - Here is some of my responses:
> 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.

marking holidays is much more different than integrating a different
calendaer system :) I would think that the former is harder since the days
do not 'sync up'.

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

I agree that kernel-level infrastructure is not needed - I don't think
glibc level is needed either - Since we have the time_t seconds since the
epoch - We can just calculate based on that (i.e. figure out what day of
the calendar it is for you on that date (date/month) - then calculate what
it is today from there) - Anyone got a generic function handy? ;)

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

This is the /MAJOR MAJOR/ headache - What you'd have to store - is the
number of months + their names + the number of days + their names. Then you
gotta the 'quirks' of the calendar - Like in the Islamic Lunar Calendar the
year can either be 360 or 361 days, depending on the holy month of ramadan
(if the moon crescent is sighted at a certain time) - so thats very
subjective (i.e. no mathmetical formula for that). On top of that some
Islamic countries see that crescent, some don't - so some countries will go
out of sync - ARGH - I do believe they sync up somehow - don't ask me how.
My point is - how would these quirks be handled - My suggestion - Allow the
user to manually sync up the 'epoch' with their 'date'  (we'll ship a
'default value' but they can modify it to suit their needs) (for leap years
whatever) - if somebody is more 'knowledgeable' with a calendar they can
hack in their own routines (i.e. leap year stuff).

What is your idea of 'modular'?

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

Yes - any more details/ideas on how this should be done though? I'm pretty
sure each lunar calendar out there is 'unique' (due to its quirks) - So?
how would this be done? Also, didn't someone email mentioning the '19 month
19 day' calendar? (weird) Maybe the calendar should be 'abstracted' out
more into the custom month (name + numer) + custom days (name + number) -
then some sort of routine to match the epoch to the current day/number.

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

See Above

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

Where can I read this iCal specification :) Easy reading or difficult? I
must admit I've never read/implemented/worked with an implementation - I
just code :)

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

Heh - just read this part after I wrote my response - My idea is to let the
user manually sync up the epoch with a date - so in that way they can
'customize' the current date :)

Yes - time is not important - Time/TimeZone is the same for both lunar and
solar:)

> -Russell