Subject: date: invalid date '1954-05-23'

From: Andras Korn <[email-masked]>
Date: Mon, 3 Dec 2012 10:26:04 +0100

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.

---

From: Bob Proulx <[email-masked]>
Date: Mon, 3 Dec 2012 02:44:17 -0700

> coreutils 8.x I could try. May 22 and May 24 are OK. Coreutils 7.1 doesn't

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

---

From: Andras Korn <[email-masked]>
Date: Mon, 3 Dec 2012 11:38:24 +0100

On Mon, Dec 03, 2012 at 02:44:17AM -0700, Bob Proulx wrote:

Hi,

> issue.  Could you say a little more about how to recreate the problem?

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?

>   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.

---

From: Bob Proulx <[email-masked]>
Date: Mon, 3 Dec 2012 04:32:32 -0700

Andras Korn wrote:
> Bob Proulx wrote:

  $ 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.

> invalid due to DST" or similar?

I would not be opposed to that.  I am even motivated to suggest that upstream!

> Thanks, but is there any guarantee that no DST changes will ever cause noon

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

---

From: Andras Korn <[email-masked]>
Date: Tue, 4 Dec 2012 17:00:04 +0100

>   $ zdump -v Europe/Budapest | grep 1954

Useful command, thanks.

> 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?