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

["Ray Lee" <ray madrabbit org>]

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?

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

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

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

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

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

 ~ ~

Other comments:

 o  What're you doing here?
    170:  addyears = (gint) totaldays / 366;

 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.

Otherwise, looks promising.

Ray Lee / ray madrabbit org ~ rblee impulse net