3 ms·

From what I can tell, there's no library to parse the full range of ISO 8601 in Python. The standard string that people claim is "just ISO 8601" ("YYYY-MM-DDTHH

From what I can tell, there's no library to parse the full range of ISO 8601 in Python. The standard string that people claim is "just ISO 8601" ("YYYY-MM-DDTHH:mm:ss.sssZ") is not full ISO 8601 compliance. ECMAScript specifies "simplified extended ISO 8601", which is just that string above.

tzs 6y ago
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.
WorldMaker 6y ago
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.)
strbean 6y ago
They should kill datetime.fromisoformat() with fire.
jcahill 6y ago
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 https://github.com/metomi/isodatetime/issues/138 [2]: https://www.loc.gov/standards/datetime/ https://www.loc.gov/standards/datetime/ [3]: https://www.loc.gov/standards/datetime/background.html https://www.loc.gov/standards/datetime/background.html [4]: https://www.loc.gov/standards/datetime/implementations.html https://www.loc.gov/standards/datetime/implementations.html [5]: https://github.com/plk/biblatex/issues/656 https://github.com/plk/biblatex/issues/656 [6]: https://github.com/ixc/python-edtf/issues/24 https://github.com/ixc/python-edtf/issues/24 [7]: https://github.com/saw-leipzig/csv2cmi/issues/18 https://github.com/saw-leipzig/csv2cmi/issues/18 [8]: https://github.com/schemaorg/schemaorg/issues/242 https://github.com/schemaorg/schemaorg/issues/242 [9]: https://github.com/JohnLukeBentley/open-datetime-standard-bootstrap/issues https://github.com/JohnLukeBentley/open-datetime-standard-bo... [10]: https://github.com/druimalban/iso8601-timestamp https://github.com/druimalban/iso8601-timestamp

tzs 6y ago

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.

WorldMaker 6y ago

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

strbean 6y ago

They should kill datetime.fromisoformat() with fire.

jcahill 6y ago

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 https://github.com/metomi/isodatetime/issues/138 [2]: https://www.loc.gov/standards/datetime/ https://www.loc.gov/standards/datetime/ [3]: https://www.loc.gov/standards/datetime/background.html https://www.loc.gov/standards/datetime/background.html [4]: https://www.loc.gov/standards/datetime/implementations.html https://www.loc.gov/standards/datetime/implementations.html [5]: https://github.com/plk/biblatex/issues/656 https://github.com/plk/biblatex/issues/656 [6]: https://github.com/ixc/python-edtf/issues/24 https://github.com/ixc/python-edtf/issues/24 [7]: https://github.com/saw-leipzig/csv2cmi/issues/18 https://github.com/saw-leipzig/csv2cmi/issues/18 [8]: https://github.com/schemaorg/schemaorg/issues/242 https://github.com/schemaorg/schemaorg/issues/242 [9]: https://github.com/JohnLukeBentley/open-datetime-standard-bootstrap/issues https://github.com/JohnLukeBentley/open-datetime-standard-bo... [10]: https://github.com/druimalban/iso8601-timestamp https://github.com/druimalban/iso8601-timestamp