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

["Ray Lee" <ray madrabbit org>]

> > == I, and > == Ali Abdin wrote:

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

Okay, I saw the code for handling leap years and days of the month and
whatnot, and worried that you were duplicating libc stuff.

> Well - Before I went ahead and did this I checked that time_t
> is a 'signed' integer.

Perhaps the glibc implementation does this, but you're just getting lucky
because of the platform. The ANSI standard strongly implies that time_t is
to be viewed as an unsigned type. It's best to stay inside the standard
since whatever comes down the line to fix the 2038 problem may change your
'platform' underneath you.

> So this implied to me you can use it to store time before the
> epoch.

Right, I understand, but I'm trying to point out that it's terribly
undefined.

> Like Russel said - what *is* the proper way of handling dates before
> the epoch?

Right, see other message.

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

The y2.038k problem is a platform dependant issue. Some platforms use an
unsigned type, and they'll have a problem 68 years later than the rest.

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

<shrug> So 'date' is getting lucky. All I'm trying to say is that this
isn't defined, and therefore we shouldn't be using it. Also, since it
really doesn't even get us back to the dates of interest (1901 is still
hundreds of years too advanced for what you need, yes?), I don't see any
use in stretching the standard.

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

No, I'm saying that you can't use dates prior to the epoch. The date of
the epoch isn't defined by the C standard, and therefore could be changed
willy-nilly to whatever the libc people desire. I'd prefer ticks of a
cesium-133 clock from the date of the big bang, but that's a tad more than
64 bits. It'd cover everything, though :-).

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

Go to the C Standard instead. The text of it is available somewhere on the
web, dunno where though. A clever google search on 'X3J11' would probably
pop it up. Also, another good reference is _The Standard C Library_ by
P.J. Plauger, the guy who chaired the ANSI committee on C. The books
covers how to implement the standard library, and is a great reference for
this and lots of other things.

> Having to call localtime/gmtime all the time to confirm the
> validity of a date seems very awkward.

Not really. Do whatever math you want on a struct tm, then, as the very
last thing you do, call mktime. It's less code than carrying around logic
for % and / by 86400 and leapyears and whatnot. If you find it to be
really cumbersome, wrap the math up into a routine.

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

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

[structs vs. param lists]
> Yes - I understand this :)

Right, sorry, I get horribly pedantic some times.

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

struct tm, maybe. It doesn't support anything earlier than 1900, though.

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

Ehh, perhaps. Usually days are characterized by the time of their first
second (midnight) and so this is a problem solved by convention.

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

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

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

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

(Speaking of which, the word wrap caught me at a bad point. The Julian Day
number as I write this is:
  991 054)

Ray Lee / ray madrabbit org ~ rblee impulse net