Re: Personal Calendar Server Volunteer? (fwd)

[rms39 columbia edu (Russell Steinthal)]

[Note: This message was composed but not sent before I saw Ali's 
latest proposal to work on a standalone calendar. -RMS]

On Sat, 05 Feb 2000 02:57:28 +0200, Ali Abdin wrote:

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

Agreed.  (I assume the lunar calendar you want to work with marks 
days as beginning/ending at sunset, rather than midnight.  If so, you 
also need to take into account the precise latitude/longitude of the 
user.  Rusty Conover's work on libastro would hopefully help with 
that problem.)

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

I have the code for the Hebrew calendar conversion in C, and if 
nobody can find anything better, GNU Emacs contains an Islamic 
calendar implementation in elisp.  It's probably worth looking at in 
any case...

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

By modular I simply meant that whatever hacking you do to get an 
Islamic calendar working in gnomecal, you implement some sort of 
generic calendar abstraction so that if someone else (me, for 
example) wants to write another calendar module, we can add it in 
later.  Basically, a "calendar module" should need to provide the 
conversion functions, some functions to work with the lengths and 
names of months and years, and that should be enough.

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

This needs to be a per-calendar library--- a standard API, as above, 
should be used, but I highly doubt there is any generic algorithm 
which will work.

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

This is actually reasonably simple- each widget cam make calls like 
this:

/* the current Hebrew year is 5760 */
num_months = calformat_months_per_year (CAL_HEBREW, 5760);
for (i=0; i<num_months; i++) {
	days = calformat_days_in_month (CAL_HEBREW, i, 5760);
	name = g_strdup (calformat_month_name (CAL_HEBREW, i);
	do_calendar_widget_stuff (name, days, day_of_first_date);
}

This should be a relatively straight-forward replacement of the 
Gregorian constants with function calls.

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

It's RFC 2445, available from an RFC repository near you.

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

That may be the best solution, but it's far from ideal- there's no 
good way to schedule future events if you don't know how many days 
there are in future months.  Assume it's month 1, day 1, and you need 
to schedule an appointment for month 3, day 1--- how do you 
distinguish the cases of wanting to schedule an appointment for 
precisely 60 days from now or on the first day of month 3, whenever 
that occurs?

(I think this is actually a perverse variant of the multiple timezone 
scheduling problem...  Sometimes you want to schedule an event at 
9:00 wherever you are, but sometimes you want everyone to be doing it 
at the same precise time, regardless of their timezone.)

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

Well... It depends on your application. :)

Jewish legal time-keeping (now only used for fixing the times of 
ritual observances) is actually based on the number of hours of 
daylight in a particular location- an "hour" during the day = 
number_of_daylight_hours/12 and an "hour" at night (i.e. after 
sunset) = number_of_nighttime_hours/12. So it needs to be 
recalculated for each location. :)

(Technically, that's not a lunar calendar problem.  But it wouldn't 
surprise me if it's common to at least one other calendar system.  
And one could concieve, at least, of a lunar calendar system which 
fixed its time reference point at sunset or moonrise, rather than 
midnight.)

-Russell