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,

Andras Korn wrote:

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

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

Hi,

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?

Thanks, but is there any guarantee that no DST changes will ever cause noon
to be skipped? :)

Andras

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

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

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

Useful command, thanks.

OK, so what's next? Should I file an upstream bug report (where?) or will
you do so/have you done so?

Andras