Reminds me of some of my difficulty convincing old C# developers to break years of DateTime habits and move on to DateTimeOffset. One round trips ISO 8601 directly and the other uses "magic" (DateTimeKind) that is sometimes (likely) wrong.

That also reminds me that .NET documentation likes to pedantically remind me that what I think of as ISO 8601 is probably more specifically IETF RFC 3339, which defines a formal BNF grammar as ISO didn't think to do that in the 80s. (Yay, standards.)

Python adds a nice twist on making time parsing confusing. It has two strptime implementations. There is time.strptime and datetime.strptime. The former has much more limited timezone handling than the later.

It took me quite a while staring at Stack Overflow answers and my code, wondering why the SO answers supposedly worked and my code did not, before I realized I had time.strptime and they were using datetime.strptime.

isodatetime for ISO 8601:2004, and eventually[1] 8601-1:2019.

python-dateutil for incomplete but stdlibbish ISO 8601:2004.

python-edtf for ISO 8601-2:2019.

However, the ISO 8601-2:2019 spec is something of a clusterfuck born out of EDTF.

Most public discourse about it can be found in various confused crossover threads from people who need open-ended dates for their projects.[2-9]

Here's a haskell implementation of ISO 8601-1:2019 and ISO 8601-2:2019, for reference.[10]

[1]: https://github.com/metomi/isodatetime/issues/138

[2]: https://www.loc.gov/standards/datetime/

[3]: https://www.loc.gov/standards/datetime/background.html

[4]: https://www.loc.gov/standards/datetime/implementations.html

[5]: https://github.com/plk/biblatex/issues/656

[6]: https://github.com/ixc/python-edtf/issues/24

[7]: https://github.com/saw-leipzig/csv2cmi/issues/18

[8]: https://github.com/schemaorg/schemaorg/issues/242

[9]: https://github.com/JohnLukeBentley/open-datetime-standard-bo...

[10]: https://github.com/druimalban/iso8601-timestamp

They should kill datetime.fromisoformat() with fire.