Bug 33829 - date only uses 32 bit values when computing seconds since 1970
date only uses 32 bit values when computing seconds since 1970
Product: Red Hat Raw Hide
Classification: Retired
Component: glibc (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2001-03-29 07:55 EST by Bill Crawford
Modified: 2016-11-24 09:57 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-30 06:40:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Bill Crawford 2001-03-29 07:55:39 EST
This leads to rather unfortunate error messages like this one:

[bill@fraser src]$ date +'%s' --date='2038/01/19 03:14:07'   
[bill@fraser src]$ date +'%s' --date='2038/01/19 03:14:08'
date: invalid date `2038/01/19 03:14:08'

How is '2038/01/19 03:14:08' an invalid date?
Comment 1 Bill Nottingham 2001-03-29 10:54:50 EST
time_t is only 32 bits.
Comment 2 Bill Crawford 2001-03-29 11:10:14 EST
Still a *very* unfortunate error message, don't you think?
Comment 3 Bernhard Rosenkraenzer 2002-08-29 16:17:45 EDT
Right... But this needs fixing in glibc's mktime() function [in the long run].
Probably won't be possible before we move time_t to 64 bit.
Comment 4 Ulrich Drepper 2004-09-30 06:40:38 EDT
The time_t type is only meant for system events.  I.e., it represents
events which happened or will happen during the runtime of the system.
 Most 32 bit platforms for the limitation.  Maybe, when the critical
year 2038 nears and there are people stupid enough to still use these
legacy system, somebody will rewrite the time_t handling.  But this
isn't going to happen here and now.

Note You need to log in before you can comment on or make changes to this bug.