Bug 485587 - RFE: 64 bit Linux time is not fully implemented
RFE: 64 bit Linux time is not fully implemented
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel (Show other bugs)
i386 Linux
low Severity medium
: rc
: ---
Assigned To: Red Hat Kernel Manager
Martin Jenner
Depends On:
  Show dependency treegraph
Reported: 2009-02-14 17:21 EST by David Savinkoff
Modified: 2009-02-18 17:48 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-02-18 16:55:18 EST
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 David Savinkoff 2009-02-14 17:21:53 EST
Description of problem:
date -d @9876543210 gives an error

Version-Release number of selected component (if applicable):
date (GNU coreutils) 5.97

How reproducible:

date -d @9876543210
in a terminal

Actual results:

[name@computer ~]$ date -d @9876543210
date: invalid date `@9876543210'

Expected results:
A date in the year 2282

Additional info:
The kernel may not have a problem, but scripts may.
Comment 1 Ondrej Vasik 2009-02-16 06:05:47 EST
Thanks for report.

Tried on x86_64 architecture with 5.3 update:
# date -d @9876543210
Fri Dec 22 21:13:30 CET 2282
# rpm -q coreutils

On 32 bit architecture it will never work as you are limited by 32-bit time_t - and that's NOTABUG, but expected behaviour and limitation of date command on 32-bit system. Changing that would mean more changes in handling and will be most likely not accepted by upstream.

Note: Problem already reported upstream few times - recent one is http://lists.gnu.org/archive/html/bug-coreutils/2009-02/msg00143.html .

Could you confirm that 32-bit architecture? Otherwise please specify exact coreutils package (rpm -q coreutils) and architecture. It worksforme on x86_64 with RHEL-5.3 coreutils and it is not expected to work on 32bit architecture.
Comment 2 David Savinkoff 2009-02-16 14:24:23 EST

From what you say, this is expected and not a bug for 32-bit systems.
I have IA-32 pentium3 CentOS 5.2 coreutils-5.97-14.el5.

Sorry for bothering, but I did not find a bug report for this one.

David Savinkoff
Comment 3 David Savinkoff 2009-02-16 21:30:07 EST

I did some digging and found this problem is not a fault with coreutils, but with glibc and the kernel. time_t and __kernel_time_t should be defined to int64_t bits on all architectures, and then the distro needs to be re-compiled.
Maybe Redhat el6 can address this.

David Savinkoff
Comment 4 Bill Nottingham 2009-02-18 16:39:11 EST
This breaks the ABI for most everything, if done in the simple way. We can't do that.

It may be theoretically possible to do something w/additional syscalls and symbol versioning; CC'ing some people. But I think it would still be impractical, just because not every library that uses time_t in its ABI will be able to be versioned properly.
Comment 5 Ulrich Drepper 2009-02-18 16:47:49 EST
Close this, it's NOTABUG.  32-bit ABIs won't have 64-bit time_t.  If you don't like this, build a time machine, go back to 1994, and make a proposal then.
Comment 6 David Savinkoff 2009-02-18 17:48:08 EST
IA-32 EL6 should be a back-port of IA-64 then, or not supported at all. What is the point of supporting something moribund? I'm sure you will have to explain this to your customers some time, so make a prepared statement.

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