Bug 33829 - date only uses 32 bit values when computing seconds since 1970
Summary: date only uses 32 bit values when computing seconds since 1970
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: glibc   
(Show other bugs)
Version: 1.0
Hardware: i386 Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2001-03-29 12:55 UTC by Bill Crawford
Modified: 2016-11-24 14:57 UTC (History)
3 users (show)

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

Attachments (Terms of Use)

Description Bill Crawford 2001-03-29 12:55:39 UTC
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 15:54:50 UTC
time_t is only 32 bits.

Comment 2 Bill Crawford 2001-03-29 16:10:14 UTC
Still a *very* unfortunate error message, don't you think?

Comment 3 Bernhard Rosenkraenzer 2002-08-29 20:17:45 UTC
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 10:40:38 UTC
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.