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
