Re: Summary of Decisions? (lunar calendar)

[rms39 columbia edu (Russell Steinthal)]

Ali,

I think I'm the most active of the gnome-pim maintainers at the 
moment, so I'll try to give you the answers you want.  I guess you 
can assume that if nobody (particularly Miguel or Federico, the other 
two maintainers) objects, and I don't change my mind :), you can 
classify my decisions in this post as "official," or at least as 
official as anything on a project like this get.

Ali Abdin wrote:

> Well - i've very quickly browsed the source using lxr of gnomecal. I 
> mainly looked at the month-item which looks like it may need to be 
> slightly 'adjusted' to fit with lunar-calendar support. One hardcoded 
> factor it appears is that you can have a maximum of 42 days per month 
> (per the canvas design). I don't think that is a problem, right?

I don't think it's a horrible limitation, since I doubt there are 
many (if any) calendar systems with months longer than 42 days.

OTOH, I suspect (but haven't looked at the code) that it could 
probably be relatively easily changed as well if needed.
 
> Also - there are two inherent problems with lunar calendar support in 
> gnome-pim. One is the UI, and the other is the 'backend' stuff - I'm 
> beginning to think the backend stuff will be easier. Also, from reading 
> the source I've noticed the 'quirks' in the calendar - e.g. 11 days were 
> just 'dropped' from the calendar for example. Weird. Note: I once wrote 
> (in TurboPascal) a calendar that calculated the starting day of the month 
> based on the date from 1,1, 1901 - it umm, worked perfectly so the 
> 'dropping of 11 days' had no effect :) but anyway - I'd like to work on 
> getting the backend in first. I am not the maintainer of gnome-pim so i 
> can not make decisions? so basically what I'm asking for is for the 
> developers/maintainer of gnome-pim to tell me how they'd like lunar 
> calendar support to be done in gnome-pim. A summary or to-do list would 
> be nice :) One request - can we just forget about time issues for now 
> (for several reasons: 1. libastro isn't done 2. We can work on that after 
> we get the dates sorted out 3. Its not as important as the rest).

The 11 days in 1752 are the result of the British Empire's conversion 
to the Gregorian calendar.  The need to properly handle them are one 
of the annoying parts of getting a Gregorian calendar "correct". :)  
(I don't even want to *think* about being i18n-correct, given that 
different countries converted to Gregorian at different times- Russia 
as late as 1919, I believe.)

Feel free to disagree, but I think the best way to handle it is as 
follows:

1. Write the Islamic <--> time_t conversions.  Stick them in a file 
which will ultimately be linked into gnomecal.  (I don't think it 
needs a separate library, but if you think it will be generally 
useful, we could write a libcalendar or the like.)
2. Modify the event editor dialog to convert Islamic dialog input 
into a time_t before it stores it in the internal structures, and to 
Islamic when it edits appointments
3. Modify the other widgets as appropriate to let them display 
Islamic info (obtained, as necessary by converting from time_t -> 
Islamic).

That should handle everything that you need, since loading and saving 
will work as before (since time_t will be converted to Gregorian at 
save time and vice versa).  You still need some way to handle 
"floating" dates, however.

I'm sure I left some elements out, but feel free to ask more specific 
design or implementation issues as they come up.

> Also - how will development work on this? my suggestion is a branch on 
> CVS cos i think this is not going to be an easy patch to just apply to 
> the main-tree or whatever (and the main tree is in feature-freeze right now).

Miguel has quite convincingly in the past explained to me why a 
branch is not a particularly good idea, and I agree.  My suggestion 
would be to do what I'm doing on iCalendar- do enough work on your 
local machine to get something which is at least compilable and 
reasonably correct, and then commit to HEAD (after it's thawed).  
Then try, as much as possible, to keep the tree "correct" as you 
gradually integrate your code into gnomecal.  (It shouldn't be too 
hard to maintain the correctness of gnomecal when it's set to 
Gregorian mode while still developing the Islamic mode; you can even 
use conditional compilation or an auto* hack to keep Islamic mode 
from building on other's machines, as long as you provide the 
requisite stubs (or #ifdef's) in the main code to keep it linking.)

However, I would prefer that you *not* commit anything, even to 
another branch, until we release 1.2- that will simply complicate 
matters when we need to merge them.  If you really want to put code 
in CVS, create a subdirectory and don't include it in the standard 
Makefile.am or configure.in, so it doesn't get built.

Hopefully, the freeze for 1.2 won't be too long- in fact, you can 
hasten its end by helping to quash as many outstanding bugs as 
possible.:)

-Russell