RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 485587 - RFE: 64 bit Linux time is not fully implemented
Summary: RFE: 64 bit Linux time is not fully implemented
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel
Version: 6.0
Hardware: i386
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Red Hat Kernel Manager
QA Contact: Martin Jenner
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-02-14 22:21 UTC by David Savinkoff
Modified: 2009-02-18 22:48 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-02-18 21:55:18 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description David Savinkoff 2009-02-14 22:21:53 UTC 
Description of problem:
date -d @9876543210 gives an error

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

How reproducible:

Type:
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 11:05:47 UTC 
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
coreutils-5.97-19.el5

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 19:24:23 UTC 
Hi,

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-17 02:30:07 UTC 
Hi,

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 21:39:11 UTC 
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 21:47:49 UTC 
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 22:48:08 UTC 
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.