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 date string. - 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 go away. 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 gnome-libs-1.4.2-3.fc6 How reproducible: Always. Steps to Reproduce: 1. Compile and the attached test case (created with glade-0.6.4) on FC6 with gnome-libs-1.x installed. 2. Run it. 3. Actual results: Described above. Expected results: The time string should contain ":" time separator both in the dropdown menu and in the time entry of the GnomeDateEdit. Additional info:
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 0:00:00. 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" 13.13.58 $ date "+%T" 13:14:01 $ date "+%R" 13:14
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.