3 ms·
I will state this briefly as a tangent. This article mentions third party libraries; the top are Arrow and Pendulum. These are a wellspring of subtle bugs due t
by the__alchemist 3y ago
I will state this briefly as a tangent. This article mentions third party libraries; the top are Arrow and Pendulum. These are a wellspring of subtle bugs due to a decision they made that I suspect is based off the Javascript library Moment: They conflate Dates, Times, and Datetimes, as a single type. If you are using their Arrow etc type to represent a Date or Time, the resulting code will be fragile, and fail in surprising ways. Additionally, if my function signature accepts a time or date, you have no way of validating the parameter, and can do things like ask for "seconds" on a date. The moment/arrow/pendulum community advocates that the concept of a date or time individually is meaningless; I disagree. It is application specific, and there are applications that call for any of the 3 variants.
Python's builtin `datetime` library has flaws as pointed out in the article, but is safer than Arrow or Moment. I think Rust's Chrono lib is the best datetime library I've seen, in terms of not surprising you with errors.
- ariebovenberg 3y agoAuthor of the article here— I actually did start out basically porting Chrono to Python, but decided against it for two reasons: 1. While I really liked handling local/UTC conversions with the "LocalResult" enum in Rust, it translated poorly to Python. Somewhere along the line you'd need to transition from Rust's "errors as values" to Python's exception-oriented world. I actually wish Python would go Rust's way, but I'm not going to swim against the current here... 2. Most modern libraries in other languages choose to disambiguate local datetimes. I felt it was safer to go the road more traveled here.