Re: [HC Evolution] Calendar to-do list

[Ali Abdin <aliabdin aucegypt edu>]

> > I also don't think its that difficult to code actually. As long as the
user
> > can sync the Gregorian/time_t with the Real World Islamic date - then
> > everything should be fine? Actually - all other software that does
Islamic
> > calendar doesn't even provide this feature - so its not really essential
> > (i.e. it can be hardcoded in and changed each year or something)
>
> Hard-coded? Ick. Here's how I imagine it could work:
>
> The special Islamic->Gregorian mapping info would be stored in a
> config file. You suggested earlier that someone could run a server
> that tells what moon phase pronouncements have been made. Someone (you
> maybe? :) writes a program (probably a perl or python script) that
> connects to that server, and checks if the real calendar has slipped
> relative to the predicted calendar. If it has, the script edits the
> mapping file (not sure if it does this by itself or via a CORBA call
> into the calendar) and then connects to the PCS, queries for any
> events scheduled on Islamic dates, and reschedules them for the
> correct new Gregorian dates. If this causes scheduling conflicts, it
> warns you about them.

Wow - really good info :) There are sites out there that actually tell you
of the moon phase proclamation /and/ provide calendars based on that (found
by just a quick browse).

I was thinking of two 'generic' functions for each type of calendar - one to
time_t and from time_t. So to convert to Gregorian, I would convert to
time_t and then gregorian would take the time_t and convert it to its format
(thats how 'saved' calendars work, right?) - I really like the idea of
contacting the PCS and doing the re-scheduling/notification stuff :) Very
very cool - but that still has the problem. How do you designate something
as "fixed" or "sliding/rolling/whatever-name-you-want-to-give-it"?

> This way, the calendar itself is simpler; it never needs to deal with
> changes in the Islamic->Gregorian mapping, because the changes always
> occur behind its back.

My thinking was to have:
Islamic -> time_t only (since thats how the spec stores stuff, isn't it?)

> Evolution is supposed to be heavily scriptable, so it should
> (theoretically) be easy to set it up to run this calendar checking
> script whenever necessary. (You just schedule it to be run on any date
> when a calendar shift could be announced.)

Sweet :) Sounds feasible

> Extremely anal people could do the same thing to query the
> International Earth Rotation Service every six months to find out if
> there's going to be a leap second, and insert it into their calendar
> if so. :-)

Thats going over board. I did read somewhere that someone was working on a
library (in windows - closed-source i believe) that would /predict/ the
visibility of a moon and tell you the likeliness of the full moon being
sighted (of course it doesn't take into account weather conditions). So now
you have a calendar program that will come up with an approximation of the
Islamic calendar based on the probability of the sighting of the moon. I
found that personally amusing :)

> On a side note: In Miguel's developerWORKS talk, he mentioned that
> since GNOME is free-like-free-beer, it has the potential to beat out
> MS in third-world countries where companies (and people) can't as
> easily afford to buy expensive software. These are also some of the
> markets that would be using non-Gregorian calendars, so having solid
> support for "weird" calendars may turn out to be a really good thing.

The only "weird" calendars that I can think of are "Islamic and Hebrew" - I
think anything else is basically extinct and unused and not worth the
effort. Anyone have objections to that? Perhaps these two can be put as
"goals" for Evolution :) but I think the real barrier to pentrating
third-world countries is:
A) localization (i.e. not much support for right-to-left on linux)
B) Lack of advocation
C) These are poor countries. They have lots of "custom" software on Windows
(i.e. databases of many many records). They can not afford the "move" to
linux (they need to hire people to write new software. Make sure all
hardware is "linux-compatible". Hire people to move the information to the
new system. etc etc.)
D) Try to get local vendors to sell/advocate linux :) (I heard of RH Linux
6.1 boxed being sold for 400 Egyptian (or approx 175$) - and this was the
50$ version)