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

[Ali Abdin <aliabdin aucegypt edu>]

> 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'
integer.
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
> moot.

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
codebase?

> > - 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
> > 'client'.
>
> 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
years).

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

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)