Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Whenever: Typed and DST-safe datetimes for Python

github.com

Post reply on HN
Print view View original

81–90 of 151 posts

Re: Whenever: Typed and DST-safe datetimes for Python

#81

Post by [deleted] »

mark-r wrote: post #47
jethkl wrote: post #38

Earlier quoted context omitted.

My hope is that a lib like this one or similar could rally mindshare and become integrated as the new standard, and adopted by the wider developer community. In near term, it comes down to trade-offs. I see no decision that works for all use cases. Dependencies introduce ticking time bombs, stdlibs should be correct and intuitive, but at least when not they are usually well tested and maintained, but when stdlib don'…

Is there any part of the Python standard library written in Rust? I would see that as a big impediment to having Whenever adopted as standard.

[deleted]

Re: Whenever: Typed and DST-safe datetimes for Python

#82

Post by scott_w »

BrandoElFollito wrote: post #79

Dates and HTTP requests are the two things I always manipulate through libraries (no matter the language, except maybe for timestamps). It is so much simpler that way. I am an amateur dev, though, so maybe someone who masters the language will be better off using the raw standard libraries.

Honestly, no. There are times when you want to get low level but, when you do, you need to commit to learning that domain as well as the problem domain you’re being paid to solve. If those are disjoint, well, have fun!

Re: Whenever: Typed and DST-safe datetimes for Python

#83

Post by Kwpolska »

ariebovenberg wrote: post #71
Kwpolska wrote: post #20

Earlier quoted context omitted.

Extras only affect dependencies, you can’t have different codebases for them. An issue was closed as not planned: https://github.com/ariebovenberg/whenever/issues/158

Author here. To summarize the long discussion in the issue: 1. I _love_ pure Python packages. Not everybody should be forced to use Rust. I want installing pure-Python to be as easy as possible 2. Having separate names on PyPi (with or without extras) creates confusion for libraries depending on whenever: should they depend on whenever-py or whenever-rust? If one “overwrites” the other, this adds confusion. 3. Most u…

1. Is the Rust version really faster enough to warrant the extra complication? Is it faster in real-life code, not only in synthetic benchmarks?

2. I would expect `pip install whenever` to give me the pure-Python version, and `pip install whenever-rust` to give me the Rust extras. Both packages can be installed at the same time; the pure-Python package detects and uses the Rust implementation if present.

Re: Whenever: Typed and DST-safe datetimes for Python

#84

Post by mark-r »

thijsvandien wrote: post #65
mark-r wrote: post #47

Earlier quoted context omitted.

Is there any part of the Python standard library written in Rust? I would see that as a big impediment to having Whenever adopted as standard.

I don’t think so, but they do offer a pure-Python version as well. https://whenever.readthedocs.io/en/latest/faq.html#how-can-i...

True, but does it suffer in efficiency? I wish they had included the pure Python version in their benchmark.

Re: Whenever: Typed and DST-safe datetimes for Python

#85

Post by [deleted] »

Kwpolska wrote: post #83
ariebovenberg wrote: post #71

Earlier quoted context omitted.

Author here. To summarize the long discussion in the issue: 1. I _love_ pure Python packages. Not everybody should be forced to use Rust. I want installing pure-Python to be as easy as possible 2. Having separate names on PyPi (with or without extras) creates confusion for libraries depending on whenever: should they depend on whenever-py or whenever-rust? If one “overwrites” the other, this adds confusion. 3. Most u…

1. Is the Rust version really faster enough to warrant the extra complication? Is it faster in real-life code, not only in synthetic benchmarks? 2. I would expect `pip install whenever` to give me the pure-Python version, and `pip install whenever-rust` to give me the Rust extras. Both packages can be installed at the same time; the pure-Python package detects and uses the Rust implementation if present.

[deleted]

Re: Whenever: Typed and DST-safe datetimes for Python

#86

Post by iknownothow »

I've read the link and the GitHub readme page.

I'm sure I'm in the top 1% of software devs for the most number of timestamps parsed. [1]

DST is not a problem in Python. It's parsing string timestamps. All libraries are bad, including this one, except Pandas. Pandas does great at DST too btw.

And I'm not shilling for Pandas either. I'm a Polars user who helicopters Pandas in whenever there's a timestamp that needs to be parsed.

Pandas has great defaults. Here's string timestamps I expect to be paesed by default. I'm willing to pass timezone in case of naive timestamps:

* All ISO 8601 formats and all its weird mutant children that differ by a tiny bit.

* 2025-05-01 (parsed not as date, but as timestamp)

* 2025-05-01 00:00:00 (or 00.0 or 00.000 or 0.000000 etc)

* 2025-05-01 00:00:00z (or uppercase Z or 00.0z or 00.000z or 0.000000z)

* 2025-05-01 00:00:00+02:00 (I don't need this converted to some time zone. Store offset if you must or convert to UTC. It should be comparable to other non naive timestamps).

* 2025-03-30 02:30:00+02:00 (This is a non existent timestamp wrt European DST but a legitimate timestamp in timestamp representation, therefore it should be allowed unless I specify CET or Europe/Berlin whatever)

* There's other timestamps formats that are non standard but are obvious. Allow for a Boolean parameter called accept_sensible_string_parsing and then parse the following:

  \* 2025-05-01 00:00 (HH:mm format)

  \* 2025-05-01 00:00+01:00 (HH:mm format)
[1] It's not a real statistic, it's just that I work with a lot of time series and customer data.

Disclaimer: I'm on the phone and on the couch so I wasn't able to test the lib for its string parsing before posting this comment.

Re: Whenever: Typed and DST-safe datetimes for Python

#87

Post by Gare »

MrJohz wrote: post #69
ljm wrote: post #60

Earlier quoted context omitted.

Not killed IME but bloated and dragged down by tech debt. E.g the JS project that uses the stdlib Date API, and pulls in moment.js, and also uses date-fns. Or the one that pulls in bits and pieces of lodash, ramda, and other functional libraries. And maybe it uses native fetch and axios depending on the current phase of the moon. They don’t die but time is wasted in code review trying to understand if there is any ki…

The Date example is possibly an even better example of why dependencies that get hard problems right are so important. If Python's datetime library is bad, Date is truly terrible. Every time I have used it I have regretted it long term (including when using it in combination with date-fns in the hope that that makes it usable). And in the end, trying to keep things simple with Date has caused more technical debt than…

Fortunately, JS is getting Temporal, which will be great. No such thing on the horizon for Python yet.

Re: Whenever: Typed and DST-safe datetimes for Python

#88

Post by qwertox »

ariebovenberg wrote: post #75
qwertox wrote: post #42

> If performance isn't your top priority, a pure Python version is available as well. Then it would have been nice to see the benchmarks of the pure Python implementation as well. What if it's worse than arrow?

Author here. It's answered briefly in the FAQ > In casual benchmarks, the pure-Python version is about 10x slower than the Rust version, making it 5x slower than the standard library but still (in general) faster than Pendulum and Arrow. "(in general)" here since the speed compares differently per operation, while the Rust version is faster across the board. That said, there's no operation that is _significantly_ (or…

Thank you. My apologies for not reading the FAQ. Also thank you for sharing your library.

Re: Whenever: Typed and DST-safe datetimes for Python

#89

Post by mdaniel »

Hasnep wrote: post #23

If you've not read the blog post that explains why this library exists I recommend it. It's called "Ten Python datetime pitfalls, and what libraries are (not) doing about it" https://dev.arie.bovenberg.net/blog/python-datetime-pitfalls...

https://dev.arie.bovenberg.net/blog/python-datetime-pitfalls... highlighted yet another thing that I hadn't previously considered and makes me plug https://infiniteundo.com/post/25326999628/falsehoods-program...> https://news.ycombinator.com/item?id=4128208>

Re: Whenever: Typed and DST-safe datetimes for Python

#90

Post by vjerancrnjak »

crazygringo wrote: post #68
vjerancrnjak wrote: post #22

Does someone know when these performance issues matter? My understanding is that datetime is a shortlived object, you wouldn't want thousands of datetime objects all over the codebase. Almost all of the time UTC is enough, if I need to filter/bucket/aggregate by some range, I can reach for datetime with tz for these filter/bucket/aggregate criteria, convert them to UTC and on continues `int` comparison. I'd imagine a…

In my experience it's for calendar-related stuff. You need to store things permanently with the timezone, especially for recurring events. You don't want your scheduled lunch to move from 12 to 1 because it's DST. And so anything server-related with calendars will be making tons of these conversions constantly. And you can't cache things long-term in UTC because the conversions of future events can change, when count…

But lunch is 12 in time, not in date. You have to decide, with short lived datetime what the desired outcome is for today.

So you would not store that in UTC but just in time.

But yes, I’m ignoring the standard of calendar formats , maybe they are simpler .

I read through the article listing all the weirdness of other datetime libraries and I’d say many were covering cases where you behave that timezoned datetime is long lived .

One case even pointed out datetime construction with an impossible hour.

Post reply on HN