Re: [Evolution] Islamic Calendar Support File (Progress!)

[Ali Abdin <aliabdin aucegypt edu>]

> > I could of course add functions that convert 'tm' structures ->
> > Islamic and vice versa - but they would rely on the time_t
> > functions.
>
> Yeah, I understand your point here, I think, and agree that the situation
> is suboptimal. My argument for what you should use is  in the other
> message.

Actually - after thinking about it some more. This won't be necessary. I
create the time_t in the first place by /using/ the tm structure. So
basically, to create a 'tm' structure from an Islamic date should be very
simple. The /internal/ respresentation of my code uses 1/1/1970. The book
uses 1/1/1 - but I thought that was a bit extreme (and unnecessary) - so I
thought it would be better to just use the epoch. (Its true that this may
change in the future - but I have to use a reference point from somewhere -
and a semi-recent one is better so the 2 calendars don't get too out of
sync). Converting a time_t to Islamic is already done. Converting a tm to
Islamic wouldn't be very difficult. I would just calculate the number of
'days' since 1/1/1970 (the reference point) which should be quite easy. My
internal representation allows for 'negative' absolute days

> > I could also 'limit' the 'conversion' functions to dates after
> > 1/1/1970 - that is very trivial - the question is SHOULD IT be
> > done?
>
> Depends. What are you trying to keep track of? For appointments time_t
> (and hence the limit) or struct tm seems fine. For other things...

To be honest - I don't know what I keep track of. I'm just trying to create
(at this point) simple convenience functions to convert to/from Evolution's
internal structure (currently time_t - but i have no idea if they're going
to change, and if so to what).

> > Umm - It can be another client. But what it would involve is
> > just coping a lot of the Gregorian code. Truly and Honestly -
> > it would be IDENTICAL code to the gregorian one except for
> > an 'Islamic way of scheduling dates' (and
> > the month names/numbers would be different)
>
> Okay, but my understanding is that a lot of the GNOME code does a sort of
> C++ style inheritance implemented via C. Since there are something like a
> half-dozen calendar systems in use, this seems like a perfect place to
> plop down an interface. For those calendars that have lots of overlap, the
> interface can be populated by pointing to the existing code.

True - but I don't think the calendar-client code is set-up for this well
(i.e. i don't think it was designed to allow it to work with two different
calendar formats). So that may take some work.

> > >  o  What're you doing here?
> > >     170:  addyears = (gint) totaldays / 366;
> >
> > I am approximating the number of years by just dividing by 366.
> > I then do a 'sequential' search until I find the exact date.
>
> Ah, okay. The length of the year is something like 365.2422 days, but as
> long as you know which direction you're off, and doing a fixup afterwards,
> life is good. I hadn't grokked that out of the code.

Yeah - I now the decimal number. But the whole point of dividing by 366 is
to just get an approximation of the year. Then to just keep checking the
absolute_date variable until it exceeds the absolute_from_gregorian stuff
(thats the condition in the for loops). To get the 'exact' number of years
given a 'number of days since 1/1/1970(or any other point in time)' directly
is not a trivial (or easy) thing to do.

The same is done for the month (except you start from '1' - no approximation
is used).

> [The use of mktime()]
> > If you can give me an example (using my current code) of where I can
> > use mktime/time instead of what I have. I'll look into it
>
> last_day_of_gregorian_month seems a candidate, but other than that I don't
> know. Your code does enough odd conversions in a row that my cursory
> glance made me think that There Must Be A Better Way (cf.,
> time_from_islamic_date()). If all the looping, etc. is to do with Islamic
> dates, then obviously mktime() isn't going to get you anything.

last_day_of_gregorian_month tells you the number of days (or 'size') of the
month. I fail to see how time and/or mktime will help me in that. Also - the
'looping' stuff evaluates the exact year/month given 'X days since 1/1/1970'
(I provide X as the input). True - we could convert/use a time_t for that -
but thats not the 'internal representation' of my code (i.e. we want to have
negative days too)

> [Integration of different calendars into Evolution]
> > You can have a tm -> Islamic and vice versa thing that depends on the
> > current time_t stuff.
> >
> > Or - it can be re-coded entirely (not trivial!!!) to do tm->Islamic
> > natively - with no time_t stuff at all.
>
> Or as above. (Find a nice split point in the code base, define an
> interface, and populate most of the interface with the existing routines.)
> This'd sidestep the problem of what types you need to export. How you
> manipulate it internally is up to you, and my thoughts on that are more
> fully covered in the previous message.

split point in the code base? sorry I do not understand.

What I think is a good idea is to create some sort of 'libcalformats'
library in Evolution that we can put this (and other calendar code) in. The
only functions to export are evolution_native_structure -> Islamic and vice
versa (each calendar format would export these two functions)