Bug 45326
| Summary: | Bug in date parsing in /bin/date (sh-utils-2.0.13) | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Zvi Har'El <rl> |
| Component: | sh-utils | Assignee: | Bernhard Rosenkraenzer <bero> |
| Status: | CLOSED RAWHIDE | QA Contact: | Aaron Brown <abrown> |
| Severity: | medium | Docs Contact: | |
| Priority: | high | ||
| Version: | 7.1 | CC: | david.madore |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2001-06-24 07:07:19 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
The most recent version of sh-utils is sh-utils-2.0.11 (dated Oct 29 2000), available at: ftp://alpha.gnu.org/gnu/fetish/sh-utils-2.0.11.tar.gz ftp://freefriends.org/gnu/fetish/sh-utils-2.0.11.tar.gz We updated to 2.0.11 on May 13. 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 1048991487 vega david ~ $ TZ=Europe/Paris date --date="2003-03-30 02:31:27+0000" +%s 1048995087 vega david ~ $ rpm -qf `which date` sh-utils-2.0.11-14 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). 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>
|
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: Explanation: 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. Solution: Upgrade sh-util-2.0 to sh-utils-2.0j, available from ftp://alpha.gnu.org/gnu/fetish/sh-utils-2.0j.tar.gz 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!).