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

Previous Next

Full log

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.

Previous Next

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