Re: glib time functions

[Ali Abdin <aliabdin aucegypt edu>]

* Havoc Pennington (hp redhat com) wrote at 22:37 on 29/11/00:
> 
> Raimund Bauer <ray pluto zserv tuwien ac at> writes: 
> > after looking at the interface-specification above and checking the
> > current api of the date-functions i believe, it would make more sense to
> > only extend the current api with new functions of the same style.
> > 2 versions come to my mind:
> > 
> > 1.) extending GDate itself and adding new g_date_* function
> > 2.) defining a new struct GDateTime and adding funtions
> >     g_dt_* with similar sytax as the g_date-functions
> >
> 
> I think the way to do it is to introduce a new object that represents
> an absolute point in time. Allow creating a GDate from that, in the
> same way you can create a GDate from time_t now. Obviously that
> conversion is timezone dependent. You should also be able to convert
> the time to time in the current timezone. The simple way to implement
> it is to use time_t, with the negative that it doesn't work outside
> the 1970-2038 range of times. GDate only works from the year 0 to the
> year 5000 or something like that anyway though.

My Islamic Calendar representation is based on time_t values or "absolute"
points in time - These "absolute" values are based on the number of days
beginning from an arbitrary point - This arbitray point chosen was 1/1/1
(Gregorian). This is based on this calendar source that JWZ pointed me to
(which is very good (it is a 250k postscript file, so if you want it, I can
email it to you to privately)

Unfortunately this approach can have error's :) i.e. during 1/1/1 the Islamic
calendar is in the "negative". The Islamic calendar will not appear until
07/19/622, or 492148 days in absolute terms (i.e. from 1/1/1).

In terms of time_t of course, this is "out of range" since we only start from
1970 (the epoch). So that needs to be handled too.
 
> I would consider the target use-case to be a calendar app. Consider
> that someone probably wants their calendar to work as they travel
> between time zones; i.e. if they change zones, then the calendar
> should automatically adjust all appointments to the local time. So
> internal storage would be in UTC I guess.

Yes, I initially started writing these functions for evolution. I recieved a
lot of discussion on the implementation from various people, but the Helix
people were not really willing to accept any work on this (I was basically
ignored). This is understandable though because they're still working on
getting decent Gregorian support. Also I believe the iCal spec doesnt yet
support other date formats.

> Operations you might expect to see would be various kinds of
> math (move time forward 3 days or 2 hours), conversion to user-visible
> printed times, parsing user input (similar to the heuristic
> g_date_parse()), parsing a deterministic format (such as the ISO time
> format), etc. I'd say to get started go through the Java and Qt APIs
> and make a list of stuff they support, then figure out the new GLib
> API that supports roughly the same things.

I could work on a GDateIslamic for you if you want (if you give me a list of
'desired' functions).

Unfortunately, I do not have time to work on this if GLib is in a feature
freeze and it will not be accepted (from before I even write the code). I'd
like interest in this before I start working on it (esp. since we're
approaching final season and I'm very busy (i.e. so if I fail, I can say "at
least I got GDateIslamic into glib ;)

> You'll want to be sure there are good test cases, along the lines of
> testgdate.

My code has tests :) (although, they are rather arbitrary ones picked by me)

Regards,
Ali