Re: glib time functions

[Havoc Pennington <hp redhat com>]

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

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.

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

Havoc