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

101–110 of 151 posts

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

#101

Post by no_wizard »

raverbashing wrote: post #72
xandrius wrote: post #56

Earlier quoted context omitted.

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 depende…

Honest question: why is it so common for software developers to not upgrade their dependencies on regular intervals?

I can’t for the life of me figure out why. If you update everything incrementally you bypass the upgrade version problem when you’re so far behind that so much has changed that it becomes an overwhelming burden.

I think frozen dependencies are a big anti pattern, and places where I work that regularly update their deps tended to have better software practices generally

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

#102

Post by paulddraper »

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…

Did OP blindly install the package?

Or do it with sight?

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

#103

Post by sirfz »

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…

Maybe something like psycopg[binary], would it be possible to separate the rust binaries as an extra which would be imported if it exists (i.e. When installed with whenever[binary]) otherwise the vanilla python version is used. Not sure of the specifics tho, just throwing out an idea

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

#104

Post by MrJohz »

Gare wrote: post #87
MrJohz wrote: post #69

Earlier quoted context omitted.

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.

Well, there's libraries like this one, which is the point here.

And even in JS, Temporal won't be available broadly for a good while yet (it will probably be rolling out in Firefox in a couple of months' time, but in Safari it's still behind a feature flag, and I don't think there's even a feature-flagged implementation for Chrome yet). In the meantime, it makes sense to use a polyfill — again a library.

By all means choose your dependencies wisely, but the point I'm trying to make is that very often a sensible use of dependencies will reduce your technical debt, and attempting to use bad approaches to complex topics just because they're built into the standard library will cause so many problems down the line.

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

#105

Post by crote »

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…

> Taking on a dependency does not relieve you of reading docs, but it also adds a further burden as you now need to trust the code. The stdlib is much more heavily tested and documented than any 3rd party library will be.

Sure, but the opposite applies as well. Sticking with the flawed stdlib means you are trusting that every single future developer is as careful in reading all the docs as you are - even when it's someone reviewing that random trivial-looking patch which is secretly hiding a massive footgun. A junior developer submitted a five-line patch touching datetime? Better schedule several hours for a proper analysis!

Or you can write your own wrapper code, of course. Which will almost certainly have worse documentation and testing than a popular third-party library.

External libraries aren't evil. When chosen properly, they relieve you of burdens. You shouldn't grab any random "leftpad"-like dependency like they are going out of fashion, but something as complicated as timezone handling is best left to code written by domain experts - which means using a library.

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

#106

Post by mixmastamyk »

Sounds like we need an industry/language-wide test suite to check these many date/time/calendar libraries against. Like the browser acid tests, though focused to baseline functionality only.

https://en.wikipedia.org/wiki/Acid3

I like this new lib (Thank You) but the name unfortunately implies the opposite of what it is. "Whenever" sounds like you don't care, but you'd only be using this if you did care! Also Shakira, haha. Hmm, pedantic is taken. Timely, precise, punctual, meticulous, ahorita, pronto, etc. I like that temporal name.

Finally, none of these links mention immutability, but it should be mentioned at the top.

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

#107

Post by ok_dad »

stavros wrote: post #62
filoeleven wrote: post #61

Earlier quoted context omitted.

The poster who you just replied to is not the same person who started the thread. I am yet another person. In addition, the original post begins with, "Am I the only one to stick with the std lib". The goalposts are stable.

Again, the library in the article removes some stdlib footguns. The footguns are there, and if you use the stdlib, you need to remove (or avoid) them yourself. There's no free lunch, and you'll either need to remove them yourself (and test that code), avoid them (and constantly remember to not hit them), or use another library. It's not a choice between "using a dependency" or "using something in the stdlib", where a…

That’s why I’m a software developer though, because I learned the footguns in the standard library. I use it before third party libraries whenever I can. I can’t understand the fear, just learn your job.

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

#108

Post by crote »

no_wizard wrote: post #101
raverbashing wrote: post #72

Earlier quoted context omitted.

> 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 depende…

Honest question: why is it so common for software developers to not upgrade their dependencies on regular intervals? I can’t for the life of me figure out why. If you update everything incrementally you bypass the upgrade version problem when you’re so far behind that so much has changed that it becomes an overwhelming burden. I think frozen dependencies are a big anti pattern, and places where I work that regularly…

Because time spent updating dependencies won't contribute to adding new features.

Besides, any update risks breaking stuff. Not freezing dependencies isn't an option, because that means any commit can cause breakage in a completely unrelated part of the codebase, in a way which can be extremely confusing to debug. And you don't really want to install the very newest versions either, better wait a week or two for someone else to run into bugs and release a .1 version.

The sweet spot is somewhere in the middle: update often enough to avoid updates becoming a massive burden, stick with fixed versions between updates. I reckon it's best to just schedule some dedicated time for it every month or two.

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

#109

Post by mdaniel »

no_wizard wrote: post #101
raverbashing wrote: post #72

Earlier quoted context omitted.

> 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 depende…

Honest question: why is it so common for software developers to not upgrade their dependencies on regular intervals? I can’t for the life of me figure out why. If you update everything incrementally you bypass the upgrade version problem when you’re so far behind that so much has changed that it becomes an overwhelming burden. I think frozen dependencies are a big anti pattern, and places where I work that regularly…

I'm glad to hear that all libraries you use honor semver religiously. For the rest of us stuck here on planet Earth it's rolling the dice what, exactly, is going to happen going from 1.7.12 to 1.7.13 for any random dep. The only way to find out is to try it and then unfuck things when it spits out some transitive error message because it turns out that package-A and package-F hate each other but only on Thursdays with a full moon

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

#110

Post by mdaniel »

mixmastamyk wrote: post #106

Sounds like we need an industry/language-wide test suite to check these many date/time/calendar libraries against. Like the browser acid tests, though focused to baseline functionality only. https://en.wikipedia.org/wiki/Acid3 I like this new lib (Thank You) but the name unfortunately implies the opposite of what it is. "Whenever" sounds like you don't care, but you'd only be using this if you did care! Also Shakira,…

Without the slightest sense of irony, I actually strongly suspect such a test suite would only be valid at one moment in time, since the timezone legislation is almost continuously in flux. That's why https://www.iana.org/time-zones> and its friend https://www.oracle.com/java/technologies/javase/tzupdater-re...> exist. As if to illustrate my point, the latest update was 2025-03-22, presumably nuking any such conformance test from Mar 21st
Post reply on HN