GNU bug report logs -
#80118
Don't just say "invalid date"
Previous Next
To reply to this bug, email your comments to 80118 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org:
bug#80118; Package
coreutils.
(Sat, 03 Jan 2026 06:00:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Dan Jacobson <jidanni <at> jidanni.org>:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org.
(Sat, 03 Jan 2026 06:00:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
$ date -d '01/30/2026 02:00 PM ET'
date: invalid date ‘01/30/2026 02:00 PM ET’
Don't just say "invalid date". Say "invalid date: weird time zone".
P.S., also consider dealing with ET.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#80118; Package
coreutils.
(Sat, 03 Jan 2026 06:11:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 80118 <at> debbugs.gnu.org (full text, mbox):
On 2026-01-02 21:59, Dan Jacobson wrote:
> also consider dealing with ET.
Good luck with that. Is that eastern Australia time, eastern European
time, eastern North America time,
Ecuador/Egypt/Eritrea/Estonia/Eswatini/Ethiopia Time, East Timor, or
something else? For what it's worth, POSIX does not allow "ET"; time
zone abbreviations must be at least 3 characters. Also, real-world
abbreviations are ambiguous, such as "IST" simultaneously standing for
time in India, Ireland, and Israel.
> $ date -d '01/30/2026 02:00 PM ET'
> date: invalid date ‘01/30/2026 02:00 PM ET’
>
> Don't just say "invalid date". Say "invalid date: weird time zone".
Yes, it'd be nice if the date parser pointed out exactly what it didn't
like.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#80118; Package
coreutils.
(Sat, 03 Jan 2026 21:51:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 80118 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert <eggert <at> cs.ucla.edu> writes:
> On 2026-01-02 21:59, Dan Jacobson wrote:
>> also consider dealing with ET.
>
> Good luck with that. Is that eastern Australia time, eastern European
> time, eastern North America time,
> Ecuador/Egypt/Eritrea/Estonia/Eswatini/Ethiopia Time, East Timor, or
> something else? For what it's worth, POSIX does not allow "ET"; time
> zone abbreviations must be at least 3 characters. Also, real-world
> abbreviations are ambiguous, such as "IST" simultaneously standing for
> time in India, Ireland, and Israel.
+1. The use of "IST" especially annoys me every once in a while since I
work with people in both India and Israel.
>> $ date -d '01/30/2026 02:00 PM ET'
>> date: invalid date ‘01/30/2026 02:00 PM ET’
>> Don't just say "invalid date". Say "invalid date: weird time zone".
>
> Yes, it'd be nice if the date parser pointed out exactly what it
> didn't like.
We could probably have parse_datetime return an enum error code, which
would allow existing programs expecting a bool to work without changes.
It would take some work to implement, though.
Collin
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#80118; Package
coreutils.
(Sat, 03 Jan 2026 23:49:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 80118 <at> debbugs.gnu.org (full text, mbox):
On 03/01/2026 21:50, Collin Funk wrote:
> Paul Eggert <eggert <at> cs.ucla.edu> writes:
>
>> On 2026-01-02 21:59, Dan Jacobson wrote:
>>> also consider dealing with ET.
>>
>> Good luck with that. Is that eastern Australia time, eastern European
>> time, eastern North America time,
>> Ecuador/Egypt/Eritrea/Estonia/Eswatini/Ethiopia Time, East Timor, or
>> something else? For what it's worth, POSIX does not allow "ET"; time
>> zone abbreviations must be at least 3 characters. Also, real-world
>> abbreviations are ambiguous, such as "IST" simultaneously standing for
>> time in India, Ireland, and Israel.
Yes location based zones are better than these abbreviations as I noted at:
https://www.pixelbeat.org/docs/linux_timezones/
> +1. The use of "IST" especially annoys me every once in a while since I
> work with people in both India and Israel.
and Ireland :)
>>> $ date -d '01/30/2026 02:00 PM ET'
>>> date: invalid date ‘01/30/2026 02:00 PM ET’
>>> Don't just say "invalid date". Say "invalid date: weird time zone".
>>
>> Yes, it'd be nice if the date parser pointed out exactly what it
>> didn't like.
>
> We could probably have parse_datetime return an enum error code, which
> would allow existing programs expecting a bool to work without changes.
> It would take some work to implement, though.
Note we have the --debug option which is a catchall for a lot of these issues,
and I think suffices for this:
$ date --debug -d '01/30/2026 02:00 PM ET'
date: warning: value 1 has less than 4 digits. Assuming MM/DD/YY[YY]
date: parsed date part: (Y-M-D) 2026-01-30
date: parsed time part: 02:00:00pm
date: error: unknown word 'ET'
date: error: parsing failed
date: invalid date ‘01/30/2026 02:00 PM ET’
cheers,
Padraig
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#80118; Package
coreutils.
(Sun, 04 Jan 2026 00:45:03 GMT)
Full text and
rfc822 format available.
Message #17 received at 80118 <at> debbugs.gnu.org (full text, mbox):
> Note we have the --debug option which is a catchall for a lot of these issues
Yes but it's overkill in this case.
My solution gets straight to the point to the user.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#80118; Package
coreutils.
(Sun, 04 Jan 2026 00:50:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 80118 <at> debbugs.gnu.org (full text, mbox):
> $ date --debug -d '01/30/2026 02:00 PM ET'
date: warning: value 1 has less than 4 digits. Assuming MM/DD/YY[YY]
What does it mean "value 1" ?
Don't tell me. Just make the error message clearer please.
And I don't see anything with less than four digits, unless you want four digit days and months...
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#80118; Package
coreutils.
(Sun, 04 Jan 2026 00:59:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 80118 <at> debbugs.gnu.org (full text, mbox):
Dan Jacobson <jidanni <at> jidanni.org> writes:
>> $ date --debug -d '01/30/2026 02:00 PM ET'
> date: warning: value 1 has less than 4 digits. Assuming MM/DD/YY[YY]
>
> What does it mean "value 1" ?
>
> Don't tell me. Just make the error message clearer please.
>
> And I don't see anything with less than four digits, unless you want four digit days and months...
It is refering to the month "01" at the start of the given date string.
Some countries use YYYY/MM/DD for dates [1].
Collin
[1] https://en.wikipedia.org/wiki/List_of_date_formats_by_country
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#80118; Package
coreutils.
(Sun, 04 Jan 2026 08:34:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 80118 <at> debbugs.gnu.org (full text, mbox):
Well okay, but it's just like "Warning: applicant lacks a ****s, assuming female. Are you sure you're really should say "warning"? I would warn only if every field is just two digits and they're all below 13 too just for to make it more fun. Or two of them are below 13. Otherwise I would just say "info:".
On January 4, 2026 8:58:16 AM GMT+08:00, Collin Funk <collin.funk1 <at> gmail.com> wrote:
>Dan Jacobson <jidanni <at> jidanni.org> writes:
>
>>> $ date --debug -d '01/30/2026 02:00 PM ET'
>> date: warning: value 1 has less than 4 digits. Assuming MM/DD/YY[YY]
>>
>> What does it mean "value 1" ?
>>
>> Don't tell me. Just make the error message clearer please.
>>
>> And I don't see anything with less than four digits, unless you want four digit days and months...
>
>It is refering to the month "01" at the start of the given date string.
>
>Some countries use YYYY/MM/DD for dates [1].
>
>Collin
>
>[1] https://en.wikipedia.org/wiki/List_of_date_formats_by_country
>
This bug report was last modified 6 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.