Description of problem:
In GNOME-1.x applications recompiled for FC6, I observed some problems
with GnomeDateEdit widgets.
1. The time entry contains bogus time separator, a "." instead
of a ":". As a consequence, certain buggy behaviour is observed.
- Setting the date first (either from the dropdown calendar or manually)
and then the time from the dropdown menu modifies the previously set
- Using gnome_date_edit_get_date() on the widget gives bad
time_t value, e.g. the bad separator stops interpreting
the time string. Altering the time string manually so
it reads correctly with ":" separators, make this problem
2. Clearing both the date and time entries and then using
gnome_date_edit_get_date() gives back the current date (+ 0:00:00)
instead of (time_t)-1. It worked on earlier systems, Red Hat 6.x,
Red Hat 7.x, RH9 and up to FC5 were tested.
Version-Release number of selected component (if applicable):
$ rpm -q gnome-libs
Steps to Reproduce:
1. Compile and the attached test case (created with glade-0.6.4) on FC6 with
2. Run it.
The time string should contain ":" time separator both
in the dropdown menu and in the time entry of the GnomeDateEdit.
Created attachment 148851 [details]
Test case for datetime problem
Created attachment 148853 [details]
GNOME 2 testcase
The attached GNOME 2 testcase works as expected from my description,
e.g. empty date entry gives (time_t)-1 which translates to 1899-12-31
I also discovered that the command line "date" gives the time separated
also with dots. The GNOME 2 test case work despite of this. The GNOME 1.x
bug may be a bad interaction between the tzdata(?) or the info set by LANG.
It is hu_HU.UTF-8 in my case, BTW.
Given that upstream isn't going to fix this, it's going to be down to you and me
to either find a fix for this (e.g. from another distro) or write one ourselves...
Created attachment 148858 [details]
Fixes for GnomeDateEdit
I came up with the attached patch that fixes the problems
I described earlier.
- invalid date entry now returns (time_t)-1
- the time dropdown contains the same entries as GnomeDateEdit on GNOME 2,
i.e. hardcoded %H:%M. The selected time string was always copied to
the time entry, which (having an incorrect format) caused problems.
- the time entry contains %H:%M:%S after doing gnome_date_edit_set_time()
and on initial gtk_widget_show()
The fix may be a bit simpler, though. Option "%X" in strftime() calls
can simply be substituted with "%R" and "%T" where appropriate.
Just checked with these commands:
$ date "+%X"
$ date "+%T"
$ date "+%R"
Created attachment 148859 [details]
GnomeDateEdit final fix
This fix implements the modified strftime() options,
works as good as the hardcoded sprintf().
gnome-libs-1.4.2-5 contains your patch from Comment #6 and has been released for
FC-6 and Rawhide.