GNU bug report logs - #80118
Don't just say "invalid date"

Previous Next

Package: coreutils;

Reported by: Dan Jacobson <jidanni <at> jidanni.org>

Date: Sat, 3 Jan 2026 06:00:02 UTC

Severity: normal

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

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

View this report as an mbox folder, status mbox, maintainer mbox


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):

From: Dan Jacobson <jidanni <at> jidanni.org>
To: bug-coreutils <at> gnu.org
Subject: Don't just say "invalid date"
Date: Sat, 03 Jan 2026 13:59:04 +0800
$ 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):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Dan Jacobson <jidanni <at> jidanni.org>, 80118 <at> debbugs.gnu.org
Subject: Re: bug#80118: Don't just say "invalid date"
Date: Fri, 2 Jan 2026 22:10:16 -0800
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):

From: Collin Funk <collin.funk1 <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 80118 <at> debbugs.gnu.org, Dan Jacobson <jidanni <at> jidanni.org>
Subject: Re: bug#80118: Don't just say "invalid date"
Date: Sat, 03 Jan 2026 13:50:17 -0800
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):

From: Pádraig Brady <P <at> draigBrady.com>
To: Collin Funk <collin.funk1 <at> gmail.com>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 80118 <at> debbugs.gnu.org, Dan Jacobson <jidanni <at> jidanni.org>
Subject: Re: bug#80118: Don't just say "invalid date"
Date: Sat, 3 Jan 2026 23:48:35 +0000
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):

From: Dan Jacobson <jidanni <at> jidanni.org>
To: Pádraig Brady <P <at> draigBrady.com>,
 Collin Funk <collin.funk1 <at> gmail.com>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 80118 <at> debbugs.gnu.org
Subject: Re: bug#80118: Don't just say "invalid date"
Date: Sun, 04 Jan 2026 08:44:09 +0800
> 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):

From: Dan Jacobson <jidanni <at> jidanni.org>
To: Pádraig Brady <P <at> draigBrady.com>,
 Collin Funk <collin.funk1 <at> gmail.com>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 80118 <at> debbugs.gnu.org
Subject: Re: bug#80118: Don't just say "invalid date"
Date: Sun, 04 Jan 2026 08:49:38 +0800
>  $ 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):

From: Collin Funk <collin.funk1 <at> gmail.com>
To: Dan Jacobson <jidanni <at> jidanni.org>
Cc: 80118 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>,
 Pádraig Brady <P <at> draigBrady.com>
Subject: Re: bug#80118: Don't just say "invalid date"
Date: Sat, 03 Jan 2026 16:58:16 -0800
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):

From: Dan Jacobson <jidanni <at> jidanni.org>
To: Collin Funk <collin.funk1 <at> gmail.com>
Cc: 80118 <at> debbugs.gnu.org, Paul Eggert <eggert <at> cs.ucla.edu>,
 Pádraig Brady <P <at> draigBrady.com>
Subject: Re: bug#80118: Don't just say "invalid date"
Date: Sun, 04 Jan 2026 16:33:43 +0800
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.