Bug 45326 - Bug in date parsing in /bin/date (sh-utils-2.0.13)
Summary: Bug in date parsing in /bin/date (sh-utils-2.0.13)
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: sh-utils   
(Show other bugs)
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Bernhard Rosenkraenzer
QA Contact: Aaron Brown
Depends On:
TreeView+ depends on / blocked
Reported: 2001-06-21 12:56 UTC by Zvi Har'El
Modified: 2007-03-27 03:45 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-06-24 07:07:19 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 Zvi Har'El 2001-06-21 12:56:58 UTC
Description of Problem:
/bin/date (sh-utils-2.0.13) has a bug in date parsing. Absolute date
like "2001-06-20 00:00:00+00:00" (Midnight, June 20, 2001, UTC)
when parsed are effected by the day-light saving proporties of the
local time zone

How Reproducible:

~$ TZ= /bin/date -u -d "1970-01-01 UTC  `/bin/date +%s \
    -d \"2001-6-20 00:00:00+0000\"` sec"
Wed Jun 20 00:00:00 UTC 2001

~$ TZ=America/New_York /bin/date -u -d "1970-01-01 UTC  `/bin/date +%s \
    -d \"2001-6-20 00:00:00+0000\"` sec"
Wed Jun 20 01:00:00 UTC 2001

Expected Results:

The First output is the correct result. It should be independent
of TZ.

Additional Information:

    date +%s -d "2001-6-20 00:00:00+000"
finds the number of seconds since the epoch, 1970-0-01 UTC. Using this number
as an argument to another invocation of date as a displacement in seconds to
the epoch itself, should give back the original date, i.e. midnigt of June
20th. However, it gives one hour later.  The result should be independent of
the local time zone, but because of a bug in the date parser
sh-utils-2.0/lib/getdate.y, the day-light saving property of the local time
zone remains significant.


Upgrade sh-util-2.0 to sh-utils-2.0j, available from

This has fixed the bug in the date parser, since sh-utils-2.0j/lib is now
identical to fileutils-4.1/lib (to convince yourself that the latter parser is
OK, note that
    touch -d "2000-6-20 00:00:00+0000" file_name

really puts the correct time stamp on the file, whatever TZ is!).

Comment 1 Zvi Har'El 2001-06-24 07:07:15 UTC
The most recent version of sh-utils is sh-utils-2.0.11
(dated Oct 29 2000), available at:

Comment 2 Bernhard Rosenkraenzer 2001-06-26 11:39:41 UTC
We updated to 2.0.11 on May 13.

Comment 3 David A. Madore 2003-03-30 10:06:38 UTC
Please reopen this bug.

It seems that the problem persists in recent versions of sh-utils in at least
some cases.  Here is a "proof":

vega david ~ $ TZ=GMT date --date="2003-03-30 02:31:27+0000" +%s
vega david ~ $ TZ=Europe/Paris date --date="2003-03-30 02:31:27+0000" +%s
vega david ~ $ rpm -qf `which date`

the second number above (1048995087) is wrong, the first (1048991487) is
correct: march 30, 2003 at 02:31:27 GMT is 1048991487 seconds post the Unix
epoch, and this should not depend on time zone; apparently, the GNU date parser
is confused by the the switch to daylite saving time in the Europe/Paris time
zone between 2003-03-30T01:59:59+0100 and 2003-03-30T03:00:00+0200, but I'm not
sure exactly what is going wrong here.

Anyway, the above output is definitely a bug in GNU date and should be forwarded
to the GNU date maintainers (if such exist).

Comment 4 Zvi Har'El 2003-03-30 11:46:12 UTC
The problem is certainly *different* from the one originally reported. Paris has
the correct output in the test originally done:

$ TZ=Europe/Paris /bin/date -u -d "1970-01-01 UTC  `/bin/date +%s \
    -d \"2003-3-30 02:31:27+0000\"` sec"
Sun Mar 30 02:31:27 UTC 2003

$ TZ= /bin/date -u -d "1970-01-01 UTC  `/bin/date +%s \ 
    -d \"2003-3-30 02:31:27+0000\"` sec"
Sun Mar 30 02:31:27 UTC 2003

This is in RedHat Linux 8.0, sh-utils-2.0.12-3.

No change in sh-utils 2.0.15 <bug-sh-utils@gnu.org>

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