GNOME Bugzilla – Bug 101538
GDate is not Y2038 clean
Last modified: 2011-02-18 16:14:11 UTC
Package: glib Product: glib Synopsis: glib is not Y2038 clean Severity: normal Priority: High Bugzilla-Product: glib BugBuddy-GnomeVersion: 2.0 glib hardcodes timestamps to 32-bits, causing failures when trying to calculate dates past January 2038. To see this, compile the following program with these flags: cc -xarch=v9 -o date-test date-test.c `/usr/gnome/bin/pkg-config --cflags --libs glib-2.0` #include <stdio.h> #include <time.h> #include <glib/gdate.h> int main() { time_t systime = 0x80000000U; char timebuf[256]; struct tm * tm; GTime glibtime = (GTime) systime; GDate * glibdate; tm = gmtime(&systime); strftime(timebuf, 256, "%c", tm); printf("System routines return: %s\n", timebuf); glibdate = g_date_new(); g_date_set_time(glibdate, glibtime); g_date_strftime(timebuf, 256, "%c", glibdate); printf("glib routines return: %s\n", timebuf); } When run it shows the problem clearly: % ./date-test System routines return: Tue Jan 19 03:14:08 2038 glib routines return: Fri Dec 13 00:00:00 1901 Bugtraq+: 4794472 ------- Bug moved to this database by unknown@bugzilla.gnome.org 2002-12-18 11:27 ------- Reassigning to the default owner of the component, gtkdev@gtk.org.
From gdate.h typedef gint32 GTime; void g_date_set_time (GDate *date, GTime time_); So, this can't be fixed without an API change; either an incompatible change (Not until glib-3.0, but we have 20-30 years to get there) or an additional API (g_date_set_time64() or whatever)
I am curious; why wasn't GTime just a typedef for "long" in the first place?
Well, hard to say at this point; I'd guess that Havoc wanted GDate to have consistent behavior on all platforms. You might also need some special handling for dates less than MININT ... due to things like the Julian/Gregorian switchover, etc.
*** Bug 102723 has been marked as a duplicate of this bug. ***
could this also be causing gnome not to log in if the date was 1904 (as can happen when the PRAM battery on Appple mac runs out). see https://launchpad.net/distros/ubuntu/+source/gnome-session/+bug/23426
As of glib 2.10 we have the still deprecated g_date_set_time() and g_date_set_time_t() accepting a system's time_t variable. I will add a comment about the reason for the deprecation to the documents.
Created attachment 146020 [details] [review] Proposed patch. This patch will also add this information to the documentation. Does it make sense to deprecate GTime completely because of this?
More information: on windows, this still doesn't work. Tor said in bug 410663 that time_t is 32bit on windows, so using time_t gives developers the wrong impression that their code is Y2038 save...
We now have GDateTime to replace both GDate and GTime, so we should be good.