bug#80118: Don't just say "invalid date"

On 03/01/2026 21:50, Collin Funk wrote:
> Paul Eggert <[email protected]> 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