GNU bug report logs - #26902
date: improve error messages for invalid dates

Previous Next

To reply to this bug, email your comments to 26902 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: bug-coreutils <at> gnu.org
Subject: good invalid dates vs. bad invalid dates
Date: Sat, 13 May 2017 01:26:49 +0800

Can you please don't say "invalid date" for everything invalid.

$ date -d @1494439601675485
date: invalid date ‘@1494439601675485’
$ date -d 1494439601675485sec
date: invalid date ‘1494439601675485sec’
$ date -d 1494439601675485seconds
date: invalid date ‘1494439601675485seconds’
$ date -d @1494439601675485
date: invalid date ‘@1494439601675485’
$ date -d @1494439601675
date: invalid date ‘@1494439601675’
$ date -d @1
四  1月  1 08:00:01 CST 1970
$ date -d @149443960167
date: invalid date ‘@149443960167’
$ date -d @14944396016
date: invalid date ‘@14944396016’
$ date -d @1494439601
四  5月 11 02:06:41 CST 2017
$ date -d @zzzzzz
date: invalid date ‘@zzzzzz’

On (info "(coreutils) Seconds since the Epoch") it says

      Traditional Unix systems count seconds with 32-bit two’s-complement
   integers and can represent times from 1901-12-13 20:45:52 through
   2038-01-19 03:14:07 UTC.  More modern systems use 64-bit counts of
   seconds with nanosecond subcounts, and can represent all the times in

Please catch the cases where the user merely has entered too many digits
for the computer in question, and say
date: too far into the future.
or
date: too far into the future for current computer.
or
date: invalid date: too far into the future for current computer.

Please don't just give the same message that you give if the user hasn't
even entered one digit.

Message #12 received at 26902 <at> debbugs.gnu.org (full text, mbox):

From: Assaf Gordon <assafgordon <at> gmail.com>
To: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>,
 26902 <at> debbugs.gnu.org
Subject: Re: bug#26902: good invalid dates vs. bad invalid dates
Date: Sun, 30 Dec 2018 22:22:04 -0700

Hello,

On 2017-05-12 11:26 a.m., 積丹尼 Dan Jacobson wrote:
> Can you please don't say "invalid date" for everything invalid.
> 
> $ date -d @1494439601675485
> date: invalid date ‘@1494439601675485’
> $ date -d 1494439601675485sec
> date: invalid date ‘1494439601675485sec’
> $ date -d 1494439601675485seconds
> date: invalid date ‘1494439601675485seconds’
> $ date -d @1494439601675485
> date: invalid date ‘@1494439601675485’
> $ date -d @1494439601675
> date: invalid date ‘@1494439601675’
> $ date -d @1
> 四  1月  1 08:00:01 CST 1970
> $ date -d @149443960167
> date: invalid date ‘@149443960167’
> $ date -d @14944396016
> date: invalid date ‘@14944396016’
> $ date -d @1494439601
> 四  5月 11 02:06:41 CST 2017
> $ date -d @zzzzzz
> date: invalid date ‘@zzzzzz’
> 
> On (info "(coreutils) Seconds since the Epoch") it says
> 
>        Traditional Unix systems count seconds with 32-bit two’s-complement
>     integers and can represent times from 1901-12-13 20:45:52 through
>     2038-01-19 03:14:07 UTC.  More modern systems use 64-bit counts of
>     seconds with nanosecond subcounts, and can represent all the times in
> 
> Please catch the cases where the user merely has entered too many digits
> for the computer in question, and say
> date: too far into the future.
> or
> date: too far into the future for current computer.
> or
> date: invalid date: too far into the future for current computer.
> 
> Please don't just give the same message that you give if the user hasn't
> even entered one digit.

Please note that the errors above (with "@") are specific to 32-bit system,
where "time_t" is a signed 32 bit integer (and thus limited to
2147483647, the infamous "Year 2038" problem).

On a 64-bit system, the range is larger (allowing dates into the far
future), and too-far values are reported:

  $ date -d @2147483647
  Mon Jan 18 20:14:07 MST 2038
  $ date -d @2147483648
  Mon Jan 18 20:14:08 MST 2038
  $ date -d @214748364800
  Sat Feb  8 04:33:20 MST 8775
  $ date -d @21474836480000
  Sat Jun 22 21:33:20 MDT 682480
  $ date -d @2147483648000000
  Wed Oct  8 12:33:20 MST 68053017
  $ date -d @214748364800000000
  date: time ‘214748364800000000’ is out of range


I'm thus inclined to close this as "wontfix", but others opinions
are welcomed.


regards,
 - assaf


P.S.
If anyone is interested in trying their hands at a patch:

The "invalid date" error originates from the
bison-generated parser indicating a parsing problem, not directly
an "integer too large" problem (a call to YYABORT in gnulib's 
"parse-datetime.y).

A good place to start is the "seconds" parsing rule here:

  https://git.sv.gnu.org/cgit/gnulib.git/tree/lib/parse-datetime.y#n968

Both "signed_seconds" and "unsigned_seconds" rules have the following
condition:

    if (time_overflow ($1.value)) YYABORT;

Instead of "YYABORT" another error mechanism could be created.

Message #15 received at 26902 <at> debbugs.gnu.org (full text, mbox):

From: 積丹尼 Dan Jacobson <jidanni <at> jidanni.org>
To: Assaf Gordon <assafgordon <at> gmail.com>
Cc: 26902 <at> debbugs.gnu.org
Subject: Re: bug#26902: good invalid dates vs. bad invalid dates
Date: Mon, 31 Dec 2018 14:24:57 +0800

Maybe it should try to pass on to the user at least an error code:
Invalid date: error code 0754,
or even better, an mention of what error it hit.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.