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 @zz
date: invalid date ‘@zz’
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 @2147483648
Sat Jun 22 21:33:20 MDT 682480
$ date -d @214748364800
Wed Oct 8 12:33:20 MST 68053017
$ date -d @2147483648
date: time ‘2147483648’ 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.
