Re: Personal Calendar Server Volunteer? (fwd)

[rconover montana edu]

On Sun, 6 Feb 2000, Russell Steinthal wrote:

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

Yes, libastro will soon be usable enough to calculate rise/set times of
many celestial objects including the sun and the moon.  It will also soon
be able to determine rise/set for another of the other 8 planets, haley's
comet and a few asteroids.

Progress is a little slow with school, I haven't committed yet since its
not in a state of usuability.  It should be soon.

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

I do believe that England puts out an approximate Islamic calendar monthly
on the web, using average projected times for visibility of a cresent
moon.  We might be able to go out on the web and grab this if its clean
and reliable.


> >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.
> 
[snip]
> 
> 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?

While coding libastro I had the idea of making a specification language
where you can actually specify these things.  Maybe not a single language
but it would be the facilities so that you could say,

Holiday = Easter + 7
Election Day = Second Tuesday in Novemember
Rusty's Birthday = August 20

There needs to be the facility to allow for holidays to be specified a
number of ways, with the help of libastro you might be able to say things
like this:

Passover Start = Sunset @ today (I don't know when exactly it is)

Soon I want to add support for equinoxes and solstices, so we can
determine seasons.

Also you should have the ability to specify a holiday after a previously
defined one.

New Years Eve = December 31
New Years Day = New Years Eve + 1 day

The generating rules would be interpreted then expressed in a format that
would be efficient for calculating them in the future, using the rules.
This calculation would incur an penalty but I beleive that it could be
done so that the effect is quite small by the use of bounding.  To store
just can arbitrary date (time_t) for a date won't work since most holidays
are specified as a specified instance of time.

Rusty
-- 
Rusty Conover        | rusty@zootweb.com 
Systems Programmer   | 406-586-5050 x242
Zoot Enterprises     | http://www.zootweb.com