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

Ali Abdin wrote:

The major things it does so far:
1) Gives the number of days since 1/1/1970 given an islamic date
2) Gives the islamic date given the number of days since 1/1/1970
(the former two should never be used 'publicly' the following two
functions depend on the former though)

Why not use localtime/gmtime and mktime instead of redoing all the std c
library work?

I'm getting the /islamic/ date - mktime does not work as that would
return the gregorian date. You can just 'convert' gregorian to Islamic
by subtracting/adding days/months/year.

I'm not re-doing any std c library work as far as I know with the above
two functions.
The function declarations are something like:

time_t time_date_from_islamic (gint month, gint day, gint year);
void islamic_from_time_t (time_t time, gint *month, gint *day, gint *year);

There is some stuff that I need comments on though:
- How should the 'error' checking be done? For example - the
mktime() function returns '-1' as an error, even though that
is a VALID time_t (1 second before 1/1/1970)

Careful, -1 is most certainly NOT a valid time. Any code that relies upon
negative time_t's is broken. In fact, some implementations define time_t
via a "typedef unsigned long time_t". And to be utterly pedantic here,
upon error the routines return the value -1 cast into a time_t, not
negative one.

(This is why, in case you're curious, the difftime function returns a
double instead of a time_t -- the difference of two times may be negative,
and therefore cannot be legally represented by a time_t.)

While we're on the subject, there's no guarantee that (time_t)0 implies 01
January 1970. The only way to be sure is to do a localtime/gmtime and
check the members of the struct tm result.

Well - Before I went ahead and did this I checked that time_t is a 'signed'
So this implied to me you can use it to store time before the epoch. Like
Russel said - what *is* the proper way of handling dates before the epoch?
There deffinately needs to be a way in my opinion. Otherwise, why the hell
is time_t 'signed' (otherwise we wouldn't have a Y2038 problem - we would
have something like a Y21XX (you do the math) problem).

By the way. I believe the 'date' command (when used to show time_t) /can/
and /will/ show negative time_t's
If you try to show a date before 1902 (or is it 1901) it will 'break' and be
unable to show it.

Hmmm - what if time_t was a 64-bit value - you're telling me we /still/ can
not use dates prior to 1970 (even though 64-bit values are so huge it
doesn't matter). Very awkward. I also tried LOOKING for documenation on
time_t (through 'man', looked at my Linux App Development book, browsed
through C headers) - there was very little documentation on it.

Having to call localtime/gmtime all the time to confirm the validity of a
date seems very awkward. The way I told the iCal spec handled appointments
and stuff was through time_t's.

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

I could also 'limit' the 'conversion' functions to dates after 1/1/1970 -
that is very trivial - the question is SHOULD IT be done?

By the way - it also makes the code much 'safer' because in one of the
functions I just 'assumed' it would work using negative time_t's (I also
then added a few test cases at the end to make sure it works) (i.e. I didn't
go through the logic in my head if it was a negative time_t)

My code will more than likely follow what Evolution has. If Evolution can
schedule stuff prior to the epoch, mine will to. If it doesn't mine won't. I
think gnomecal and the current Evolution do support it though.

- Should the functions be in the month/day/year arg formats?

Any time you have a group of parameters that only make sense when taken
together, it's a prime target for a structure. This would make the problem

Yes - I understand this :) One of my TODO items was to make an
EvolutionIslamicDate structure :) Anyway, is there some sort of structure
that has the month/day/year/time stuff that I can incorporate into my

- Someone told me on IRC that it doesn't make sense to get
time_t's from a a date.

Eh? time_t's are the fundamental time type for the C library. How does it
not make sense?

time_t represents a specific 'instance' of time. not a date. So getting the
time_t for 3/25/1999 doesn't make sense really. But getting the time_t for
5:30:00 on 3/25/1999 does make sense. Right now I only handle 'dates' not
'specific instances of time' - I need to chaneg my 'conversion' functions to
handle 'specific instances in time' and not 'broad general dates'

This made sense to me. i.e. Once the EvolutionTime (For
timezone's) is done

Grrreeeeaaaat. Okay, I'm about to stick my foot in my mouth here, but
foreknowledge isn't going to stop me. Why is there an EvolutionTime when
the standard C library handles times just fine by itself? I can see
needing to add code to deal with other timezones other than your own
(converting from them to localtime), but after that, what else do you
really need?

See Russel Steinthal's post :)

- Finally, it was discussed earlier that a 'different' calendar
format should just be a different 'view' (in the MVC model).
In other words the Islamic calendar should just be another

In general, that sounds very correct. I can't speak to specifics without
looking at the Evolution codebase, which I won't be able to do for another
few weeks yet. So, write me down as 'tentative disagreement.'

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). That seems like an awful lot of
code duplication for two tiny things. Time will be handled the same way in
Islamic and Gregorian by the way.

All you need for the current codebase is the ability to rename the days
and/or months - have the ability to switch to 'islamic mode' (would re-draw
the calendar using the Islamic name, and number of days from the Islamic
month). By the way - in Islamic we have the same days per week - so thats no
problem for 'Week View' (in fact they're the exact same days if its Sunday
in Gregorian its Sunday in Islamic (in arabic its El-Ahd)). The only "big"
thing in my opinion is the way to schedule dates in Islamic mode. That is
the difficult part. Please lets avoid code duplication.

 ~ ~

Other comments:

 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.  Hrmm, I'm not sure, but I
think I should be dividing by 365 to be absolutely correct (but the
book/chapter I was using as guideline used 366 - and it works - 365 will
also work - so it doesn't really matter unless it starts giving us incorrect

Anyway - the absolute_from_gregorian is the 'odd' function out of the lot.
It uses 1/1/1 as the 'absolute' reference point (hence I subtract
absolute_from_gregorian(1/1/1970) in a few places). Ideally, I should
convert that function to use 1/1/1970 as the 'absolute' reference point. But
that should be an easy (but tedious) thing to do I think and we can worry
about it later.

 o  You do know that mktime canonicalizes its argument before doing
    anything with it, right? For example, you can get the date 392 days
    in the future by doing a localtime of time(0), adding 392 to
    tm_yday, and then calling mktime on the result. mktime() is
    guaranteed to fix the time up to something that makes sense. In
    fact, this is the only blessed way of doing math with dates or
    times, according to the ANSI C standard.

    With this, you can pull out a lot of the code you've written for
    manipulating Gregorian calendar dates.

I based my functions on the Emacs lisp calendar stuff. The only gregorian
date manipulation stuff I really do is 'sequential searches' to find the
exact year or exact month (then I find the days by subtracting). 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 (note - I'm on windows right now,
so I don't have my source code handy)

Otherwise, looks promising.

Thanks :) Now if only I can get Federico to comment on some sort 'plan' to
integrate it into evolution (note: It doesn't have to be used or even
'compiled by default')

Okay --- I thought about this for a while. There are two approaches. You can
have a tm -> Islamic and vice versa thing that depends on the current time_t

Or - it can be re-coded entirely (not trivial!!!) to do tm->Islamic
natively - with no time_t stuff at all. Then Evolution itself would have to
do a 'mktime' on the resulting code or whatever. I don't "like" this way,
and it has no advantage over the previous way (just as long as we make sure
in the previous way that time_t can not be negative)

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