Package: coreutils
Version: 8.20-1
Severity: normal
Hi,
date -d "May 23 1954" and date -d 1954-05-23 both fail in all versions of
coreutils 8.x I could try. May 22 and May 24 are OK. Coreutils 7.1 doesn't
barf on May 23 either.
Best regards,
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.5.7-vs2.3.4.3-hellgate (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages coreutils depends on:
ii dpkg 1.16.9
ii install-info 4.13a.dfsg.1-10
ii libacl1 2.2.51-8
ii libattr1 1:2.4.46-8
ii libc6 2.13-36
ii libselinux1 2.1.9-5
coreutils recommends no packages.
coreutils suggests no packages.
-- no debconf information
--
Andras Korn <korn at elan.rulez.org>
Freedom is doing what you like, happiness is liking what you do.
Subject: Re: Bug#695005: date: invalid date '1954-05-23'
Date: Mon, 3 Dec 2012 02:44:17 -0700
Andras Korn wrote:
> date -d "May 23 1954" and date -d 1954-05-23 both fail in all versions of
> coreutils 8.x I could try. May 22 and May 24 are OK. Coreutils 7.1 doesn't
> barf on May 23 either.
Thank you for the report. However I was unable to reproduce this
issue. Could you say a little more about how to recreate the problem?
What is your timezone?
For example I tried these:
$ env TZ=America/Denver date -R -d "1954-05-23"
Sun, 23 May 1954 00:00:00 -0700
$ env TZ=America/Chicago date -R -d 'TZ="UTC" 1954-05-23'
Sat, 22 May 1954 19:00:00 -0500
However since you specified the time at midnight (by not specifying a
time, always specify a time such as 12:00 noon to avoid DST issues) I
am confident the issue will be a Daylight Saving Time change in your
timezone which skips that time in your timezone. If the time has been
skipped in your timezone then that time will be listed as invalid.
Specify 12:00 noon or UTC to avoid DST issues.
Please see the FAQ entry which has examples of diagnosing and avoiding
DST problems:
http://www.gnu.org/software/coreutils/faq/#The-date-command-is-not-working-right_002e
Bob
Acknowledgement sent
to Andras Korn <[email protected]>:
Extra info received and forwarded to list. Copy sent to Michael Stone <[email protected]>.
(Mon, 03 Dec 2012 10:48:03 GMT) (full text, mbox, link).
Subject: Re: Bug#695005: date: invalid date '1954-05-23'
Date: Mon, 3 Dec 2012 11:38:24 +0100
On Mon, Dec 03, 2012 at 02:44:17AM -0700, Bob Proulx wrote:
Hi,
> > date -d "May 23 1954" and date -d 1954-05-23 both fail in all versions of
> > coreutils 8.x I could try. May 22 and May 24 are OK. Coreutils 7.1 doesn't
> > barf on May 23 either.
>
> Thank you for the report. However I was unable to reproduce this
> issue. Could you say a little more about how to recreate the problem?
> What is your timezone?
Europe/Budapest.
Apparently May 23 1954 was the date something about DST was changed in CET.
date(1)'s behaviour may in fact be correct, but the error message is confusing,
as obviously 1954 did have a May 23 even in Central Europe. :) Maybe
the message could be made more specific? Like "1954-05-23T00:00:00 CET is
invalid due to DST" or similar?
> Please see the FAQ entry which has examples of diagnosing and avoiding
> DST problems:
>
> http://www.gnu.org/software/coreutils/faq/#The-date-command-is-not-working-right_002e
Thanks, but is there any guarantee that no DST changes will ever cause noon
to be skipped? :)
Andras
--
Andras Korn <korn at elan.rulez.org>
Boeing: The sound a plane makes when it hits the ground.
Subject: Re: Bug#695005: date: invalid date '1954-05-23'
Date: Mon, 3 Dec 2012 04:32:32 -0700
Andras Korn wrote:
> Bob Proulx wrote:
> > What is your timezone?
>
> Europe/Budapest.
>
> Apparently May 23 1954 was the date something about DST was changed in CET.
$ TZ=Europe/Budapest date -R -d '1954-05-23'
date: invalid date ‘1954-05-23’
Yes. For 1954 here is when they changed:
$ zdump -v Europe/Budapest | grep 1954
Europe/Budapest Sat May 22 22:59:59 1954 UTC = Sat May 22 23:59:59 1954 CET isdst=0 gmtoff=3600
Europe/Budapest Sat May 22 23:00:00 1954 UTC = Sun May 23 01:00:00 1954 CEST isdst=1 gmtoff=7200
Europe/Budapest Sat Oct 2 21:59:59 1954 UTC = Sat Oct 2 23:59:59 1954 CEST isdst=1 gmtoff=7200
Europe/Budapest Sat Oct 2 22:00:00 1954 UTC = Sat Oct 2 23:00:00 1954 CET isdst=0 gmtoff=3600
And so as you can see DST changed at Sat May 22 23:59:59 1954 CET and
jumped directly to Sun May 23 01:00:00 1954 CEST with no "legally"
valid seconds between those two times. (This is one of the very few
times in software when it is literally an "illegal" value.)
To avoid this it would be best to use UTC.
> date(1)'s behaviour may in fact be correct, but the error message is confusing,
> as obviously 1954 did have a May 23 even in Central Europe. :) Maybe
> the message could be made more specific? Like "1954-05-23T00:00:00 CET is
> invalid due to DST" or similar?
I would not be opposed to that. I am even motivated to suggest that upstream!
> > Please see the FAQ entry which has examples of diagnosing and avoiding
> > DST problems:
> >
> > http://www.gnu.org/software/coreutils/faq/#The-date-command-is-not-working-right_002e
>
> Thanks, but is there any guarantee that no DST changes will ever cause noon
> to be skipped? :)
No. There is an old saying. "No man's life, liberty, or property are
safe while the legislature is in session." Just as a humorous note
this is of course an act of law and not technology. :-) That is why
timezones are a table lookup and changes whenever people and
governments decide to change it. But I know of no timezone that is
presently problematic when using 12:00 noon and that provides a nice
anchor point for people who wish to work with dates in a specific
timezone and not UTC. I think it quite unlikely that anyone would
make a DST change at 12:00 noon.
The best solution is to UTC. Either use date's -u option or set TZ to
UTC as appropriate. FOr this case of the simple -d then using -u is
the best solution.
$ date -u -R -d '1954-05-23'
Sun, 23 May 1954 00:00:00 +0000
$ TZ=UTC date -R -d '1954-05-23'
Sun, 23 May 1954 00:00:00 +0000
Doing it that way will avoid all DST problems.
Bob
Acknowledgement sent
to Andras Korn <[email protected]>:
Extra info received and forwarded to list. Copy sent to Michael Stone <[email protected]>.
(Tue, 04 Dec 2012 16:09:03 GMT) (full text, mbox, link).
Subject: Re: Bug#695005: date: invalid date '1954-05-23'
Date: Tue, 4 Dec 2012 17:00:04 +0100
On Mon, Dec 03, 2012 at 04:32:32AM -0700, Bob Proulx wrote:
> $ zdump -v Europe/Budapest | grep 1954
Useful command, thanks.
> > date(1)'s behaviour may in fact be correct, but the error message is confusing,
> > as obviously 1954 did have a May 23 even in Central Europe. :) Maybe
> > the message could be made more specific? Like "1954-05-23T00:00:00 CET is
> > invalid due to DST" or similar?
>
> I would not be opposed to that. I am even motivated to suggest that upstream!
OK, so what's next? Should I file an upstream bug report (where?) or will
you do so/have you done so?
Andras
--
Andras Korn <korn at elan.rulez.org>
Do files get embarrassed when they get unzipped?
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.