After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 101538 - GDate is not Y2038 clean
GDate is not Y2038 clean
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: general
unspecified
Other other
: Normal normal
: ---
Assigned To: Sven Herzberg
gtkdev
: 102723 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2002-12-18 16:27 UTC by Bugtraq+/Bugzilla Gateway
Modified: 2011-02-18 16:14 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Proposed patch. (468 bytes, patch)
2009-10-22 07:48 UTC, Sven Herzberg
none Details | Review

Description Bugtraq+/Bugzilla Gateway 2002-12-18 16:27:52 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.

Comment 1 Owen Taylor 2002-12-18 17:57:29 UTC
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)
Comment 2 Colin Walters 2002-12-18 22:22:01 UTC
I am curious; why wasn't GTime just a typedef for "long" in the first
place?
Comment 3 Owen Taylor 2002-12-18 23:43:41 UTC
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.
Comment 4 Owen Taylor 2003-01-07 14:45:19 UTC
*** Bug 102723 has been marked as a duplicate of this bug. ***
Comment 5 sam tygier 2006-04-01 12:09:31 UTC
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
Comment 6 Sven Herzberg 2009-10-22 07:40:26 UTC
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.
Comment 7 Sven Herzberg 2009-10-22 07:48:32 UTC
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?
Comment 8 Sven Herzberg 2009-10-28 14:48:43 UTC
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...
Comment 9 Matthias Clasen 2010-08-26 03:35:47 UTC
We now have GDateTime to replace both GDate and GTime, so we should be good.