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

I could of course add functions that convert 'tm' structures ->
Islamic and vice versa - but they would rely on the time_t

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

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

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)

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]