Whenever: Typed and DST-safe datetimes for Python • Hacker News Board

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

#71

Post by ariebovenberg » Sun, Apr 13, 2025, 3:47 PM UTC

Kwpolska wrote: post #20

stavros wrote: post #10

Earlier quoted context omitted.

That seems like an easy fix, they could release it as `whenever[pure]`. It would probably take less time to write up the issue than to write your comment.

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 users expect to “pip install whenever” and start using the “fast” version

For me, points (3) and (2) weigh heavy enough to make (1) slightly more cumbersome.

But: Maybe I’ve missed something. Have a read in the above issue or add your 2 cents.

edit: formatting

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

#72

Post by raverbashing » Sun, Apr 13, 2025, 3:52 PM UTC

xandrius wrote: post #56

raverbashing wrote: post #37

Earlier quoted context omitted.

A library that goes "poof" when you need to upgrade it is also a hidden debt

A service goes poof, a library either slowly deteriorates or breaks just as easily as a self-written one (if an underlying platform breaks it for some reason). The self-written one is maintained by 1 person, the other is used by 100+ people who could jump in a collaborate on its fixing. I would still rather using a library for dates, a million times so.

> a library either slowly deteriorates or breaks just as easily as a self-written one

Yes, I agree with this

> The self-written one is maintained by 1 person, the other is used by 100+ people who could jump in a collaborate on its fixing.

Libraries that have 100 people collaborating on it are very few

Most likely you'll have to vendor it and fix whatever issues you have.

Even worse when it's a dependency of a dependency and you also use it, so, let's say a dependency of yours bumps the version but this breaks your code. (Not sure this breaks only in python or in js as well, but it's possibly that it does)

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

#73

Post by [deleted] » Sun, Apr 13, 2025, 3:52 PM UTC

maleldil wrote: post #67

jessekv wrote: post #63

Earlier quoted context omitted.

I recently learned that there is datetime.UTC which is an alias of datetime.timezone.utc It helps a bit with the verbosity: from datetime import datetime, UTC datetime.now(UTC)

That's from 3.11 onwards.

[deleted]

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

#74

Post by skeledrew » Sun, Apr 13, 2025, 3:57 PM UTC

I go for Arrow when I want anything beyond the basics. This looks pretty interesting, not really because of the greater coverage in edge cases, but because while it has a Rustified mode, a pure Python mode is also available. If I do use whenever, I don't have to worry about having something else or falling back to datetime if I want better datetime handling in a project on my phone, or in some other environment where the Rust toolchain is non-existent or problematic. Kudos.

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

#75

Post by ariebovenberg » Sun, Apr 13, 2025, 3:58 PM UTC

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 unnecessarily) slower than Arrow or Pendulum.

edit: I'm considering adding comparison to the pure Python version once I get the time for a more expanded "benchmarks" page in the docs

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

#76

Post by jiggunjer » Sun, Apr 13, 2025, 4:01 PM UTC

wodenokoto wrote: post #7

Funny it doesn’t add comparison to date times in pandas, which is probably used to handle more dates than any of the others.

Pandas uses stdlib or numpy for it seems.

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

#77

Post by johnfn » Sun, Apr 13, 2025, 4:07 PM UTC

apeters wrote: post #9

Am I the only one to stick with the std lib, read the docs and changelogs carefully, and implement functions I really need the way my application makes use of them? I learned the hard way, that dependencies kill projects. Not saying this isn't great, thanks for creating it! It does have its use cases, of course.

I think this is fairly unrealistic. Does all your datetime manipulation involve proper use of the fold parameter as indicated in the article?

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

#78

Post by snvzz » Sun, Apr 13, 2025, 4:26 PM UTC

brookst wrote: post #59

gjm11 wrote: post #26

Earlier quoted context omitted.

Who wants clock noon to be the midpoint of the workday? The canonical working hours are 9am to 5pm [Parton 1980] whose midpoint is at 1pm. Many people work earlier and/or later, but my impression is that it's pretty unusual to have the midpoint at noon. ( Schools tend to have earlier times. It's not so unusual for a school's workday to have its midpoint at about noon, I think.)

9-5 sounds so luxurious in today’s 8-6 world where comms start at 7am and wrap up around 9pm.

I hope you get paid for being on-call those hours.

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

#79

Post by BrandoElFollito » Sun, Apr 13, 2025, 4:32 PM UTC

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.

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

#80

Post by oefrha » Sun, Apr 13, 2025, 4:34 PM UTC

globular-toast wrote: post #32

stavros wrote: post #21

Earlier quoted context omitted.

> Am I the only one to stick with the std lib, read the docs and changelogs carefully I work in healthcare. If I have a choice between "reading docs/changelogs carefully, implementing functions", and "adding an extra dependency", I'm taking the dependency every single time. I don't want footguns in my code, I don't want code I have to write and test myself, and I don't want to have to become an expert in a domain bef…

> I work in healthcare. If I have a choice between "reading docs/changelogs carefully, implementing functions", and "adding an extra dependency", I'm taking the dependency every single time. This kinda sums up the sorry state of software engineering. People can't even be bothered to read docs but will just blindly install a package just because someone was able to package it and upload it to PyPI. Taking on a depende…

The stdlib datetime module is in more of a sorry state than certain third party libraries and is full of footguns, as you, a read-the-docs-and-changelogs-carefully person, can surely tell from the myriad deprecations and warnings added over the years, not to mention the confusing params like tz and tzinfo. Heavily tested doesn’t mean shit when the semantics of the API is fundamentally flawed and can’t be updated.