Re: gnome_date_edit questions

Kevin Handy <> writes: 
> 1. How do I convert a date into a time_t for this widget?
>    I've tried setting fields in a 'struct tm' and running it
>    through mktime, attempted to use strptime with equally poor
>    results.

mktime() should work fine. struct tm is tricky, you might want to use
it via g_date_to_struct_tm() to be sure you have a valid struct tm (on
Linux it has weird nonstandard fields that have to be initialized).

> 2. Why does the gnome_date_entry use a time_t instead of
>    or in addition to the date format used by glib?

Mostly because it's actually a time entry (at least optionally), and
GDate only represents dates. Also I think it predates GDate.

We need a glib time representation in addition to GDate. Then the
widget should use the time representation when in "time mode" and
GDate in date mode. IMO anyway.

> 3. Doesn't the time_t greatly limit the range of dates that can
>    be handled to the range of 1970 to 2038 on 32bit machines,
>    and 64 bit machines can't represent anything before 1970?
>    I'm going to need dates before 1970, and after 2038 in a
>    lot of applications (Accounting stuff).

Yep, it is broken.

> 4. Should I just create a new date widget or modify the existing
>    one to use a different format to get past these limitations
>    (like struct tm), and what should I call it?

Well for a current app you're pretty much stuck cut-and-pasting
GnomeDateEdit and then fixing it. However if you fix it and want to
send us patches for GNOME 2.0 it would be appreciated.

While you're at it it should use g_date_set_parse() to parse typed-in
dates.:-) Worth fixing.

The date aspect of the widget should be easy to fix using
GDate. Really fixing the time aspect requires a Time type in glib


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]