Re: Personal Calendar Server Volunteer? (fwd)

[Ali Abdin <ALIABDIN aucegypt edu>]

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

The Islamic lunar calendar does not do this - Time is based on the 
position of the sun (actually, religously, time is based around prayers 
which is based around the position of the sun (but very inaccurate i.e. 
"sunrise" "noon" "afternoon" "sunset" "night") - anyway, for all intents 
and purposes and stuff in the Islamic lunar calendar they just use normal 
timezone time - All governments use it. All countries use it. 
(arab/Islamic-wise)
 
> 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...

Where can i find/locate the islamic calendar implementation?
 
> 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.

I'm beginning to think this would be better than an XML file - Although 
an XML file still could work - for example, you would just 'designate' a 
function as 'leap-year' for example and then the code would 'handle' the 
leap-yearness based on the type of the calendar.

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

I'm beginning to think a standard API would be better - How would you go 
about working in 'calendar modules' in gnome-pim then? I don't like the 
idea of making Gregorian a module (more trouble than its worth? most 
people will be using Gregorian). For example each module should have a: 

native_to_gregorian and gregorian_to_native function - The user can 
'view' the schedule stuff in their 'native' format - but internally the 
'events/schedule' would be stored using Gregorian?
 
> It's RFC 2445, available from an RFC repository near you.

Saw it - didn't understand it :P (I don't know how to read specifications 
or interpret them - unless someone wants to "dumb it down" and explain it 
to - i prolly won't be able to understand it for another two-three years)

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

Yeah - this is a big problem. What you could do is when specifying an 
appointment date have a 'toggle' button underneath asking them for it to 
be a 'days to appointment' (e.g. 60 days from now) or an exact date 
(month 3, day 1). Naturally you should be able to also specify a 
gregorian date (or any other date) and have it naturally interpreted to 
your native format (through the native_to_gregorian and gregorian_to_native)
 
> 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.)

The question is - is it worth the hassle? Does anyone ACTUALLY use this 
time format? I STRONGLY doubt that Jewish Rabbis will be using gnomecal 
anytime in the immediate future. I just disadvtanges from this 
(dependency on libastro for the 'jewish module', more confusion, 
time/effor wasted.) - If someone is truly interested though - they can 
hack it in. :)