Re: Personal Calendar Server Volunteer? (fwd)

[rms39 columbia edu (Russell Steinthal)]

On Mon, 07 Feb 2000 11:00:09 +0300, Ali Abdin wrote:

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

While you're right that using a different *time* system is probably 
irrelevant, I do think that the day should start at the correct time. 
 At least for the Hebrew calendar, it would be simply *wrong* to say 
that the day changes at midnight.  For example, right now, it's 1:00 
PM on 1 Adar I 5760.  In 7 hours, however, it will be 8:00 PM on 2 
Adar I 5760- the day will have changed at sunset, localtime.  8:00 PM 
on 1 Adar I 5760 was "yesterday" on the Gregorian calendar (16 hours 
or so ago).
 
>> 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?

On my installation, it's in /usr/share/emacs/20.4/lisp/calendar/cal-is
lam.el.
 
>> 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.

Eh?  I still think you're conflating two issues.  While a "module" 
could read its leap years from an XML file if it chose to, the 
gnomecal core should simply ask the module how many months/days there 
are in the year, and let the module do whatever it wants.  So that if 
one module uses an algorithm, so be it.  If another uses an XML 
lookup, ditto.

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

Internally, events will be stored in something akin to:

typedef struct { time_t t, TimeZone* tz } GnomeCalTimeType;

(currently it's just time_t, but it's going to have to change for 
other reasons).

So let's assume you're using the UI in Islamic mode:

1. You open the event editor and schedule an event for 2 Dhu al-Qada 
1420, 20:00 UTC. (If Emacs' implementation is correct, that's about 
an hour and a half from now.)

2. The client calls islamic_to_time_t () to convert that time, and 
calls the standard add_event function.

What else do you need?  The client/server interface, as I understand 
it (since Federico is still working it), is that the client requests 
the server send it all events within a specific range of time_t's, 
such as a day or a month.  So your UI in Islamic mode would simply 
calculate the appropriate time_t's for a given date's start and end 
and use the existing interface.

For that matter, doing the sunset-to-sunset days wouldn't be that 
much more difficult- just compute the time_t for sunset, rather than 
midnight on the given day.  Libastro can do that.

The rest of the changes are UI issues- changing date formats, date 
labels, drop down boxes, etc.  You can either implement these changes 
in the core gnomecal/evolution client, or you could, in theory, write 
a separate client, since Evolution is going to have a client-server 
separation in the client anyway.  I think it's neater to do it in the 
main client, provided the widget changes required aren't too hairy.  
If you're willing to use a simpler interface, however, it may be 
easier to code one from scratch and then just use the client-server 
CORBA interface.

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

It's not particularly important, since the only relevant section says 
that non-Gregorian calendar scales are undefined.

You have two options for loading/saving, as I see it:

1. Do a Gregorian -> Islamic conversion at load-time and an Islamic ->
 Gregorian at save-time- this means inserting calls to your 
conversion routines into the load and save routines we already have.

2. Define a standardized way of storing Islamic dates, submit it to 
the IETF as a proposed extension to the iCalendar specification, and 
then hack it into the parsing library (libical) or convince its 
author to implement your new extension.

The latter is more socially-redeeming and will theoreticlly 
interoperate with other systems.  The former seems a lot simpler.  
Your call. :)

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

That's generally the same UI concept Federico and I have discussed 
for handling group scheduling when the participants are in multiple 
timezones- you need to give the user the ability to select whether 
they want "fixed" or "floating" time.  I don't know how it well it 
will actually work as a UI, but I can't think of a better way either.

This actually complicates the load/save issue above: fixed times 
(month 3, day 1) can't be stored as Gregorian dates, since their 
Gregorian equivalent is indeterminant.  You'll need to define some 
way to store an indicator, whether in an X-Property or a full-scale 
date representation....

Hope this helps- feel free to keep bouncing ideas off me and the 
list.  Note that gnome-pim HEAD is currently in feature freeze for a 
1.2 release, so you should hold off on committing/submitting any 
patches for the time being.

-Russell