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

111–120 of 151 posts

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

#111

Post by stavros »

ok_dad wrote: post #107
stavros wrote: post #62

Earlier quoted context omitted.

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.

If your approach to footguns is "just learn your job", I'm sorry, but you aren't a very good software developer.

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

#112

Post by mdaniel »

fragmede wrote: post #99
schrodinger wrote: post #98

Earlier quoted context omitted.

Where do I find a software engineering job that has night shifts?

Remote job for a company in a different time zone

Spoken as if 80% of the software engineer workload isn't attending status update meetings to provide updates on why nothing is getting done

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

#113

Post by fragmede »

mdaniel wrote: post #112
fragmede wrote: post #99

Earlier quoted context omitted.

Remote job for a company in a different time zone

Spoken as if 80% of the software engineer workload isn't attending status update meetings to provide updates on why nothing is getting done

I'm not saying it isn't, but when the 9am scrum meeting is at 4pm your time, you can be quite the night owl!

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

#114

Post by mixmastamyk »

mdaniel wrote: post #110
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 confor…

It would have to take the real world into account, no? Additionally it could test various timezone definition permutations without necessarily being dependent on a real one.

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

#115

Post by no_wizard »

mdaniel wrote: post #109
no_wizard wrote: post #101

Earlier quoted context omitted.

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

They don’t all follow semver perfectly or in some cases at all, but we have an interval when we do upgrades.

Our test suite is comprehensive and will catch most breakages automatically. The key to success is robust testing, as it cuts the manual footprint significantly.

This does mean we are quite judicious with selecting dependencies.

It isn’t all that complicated when everyone is following best practices most of the time I have found[0]

It still leavings me wondering in a lot of cases

[0]: perhaps this is the real heart of the issue is best practices are systematically ignored. I’ve worked at places like that and it’s no wonder they grind through folks

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

#116

Post by barbazoo »

stavros wrote: post #21
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.

> 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 get where you’re coming from. There’s a price you pay though eventually. You’ll have to thoroughly vet all your dependencies for malicious code at some point. Otherwise how do you have any clue what you’re running?

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

#117

Post by NeutralForest »

mdaniel wrote: post #110
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 confor…

In that case, you'd have unit tests that confirm behaviors like compatibility or failure of some operations between types and integrations tests which pull an up to date DB of rules and tests against that.

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

#118

Post by no_wizard »

crote wrote: post #108
no_wizard wrote: post #101

Earlier quoted context omitted.

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

That’s why we do it on an interval and not when it’s first available. Avoids bleeding edge bugs but prevents the overwhelming factor of being years out of date. It typically gets handed out at the end of the month or there about.

Being judicious in selecting dependencies goes a long way too. Not always easy but certainly worth the time

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

#119

Post by mdaniel »

no_wizard wrote: post #115
mdaniel wrote: post #109

Earlier quoted context omitted.

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

They don’t all follow semver perfectly or in some cases at all, but we have an interval when we do upgrades. Our test suite is comprehensive and will catch most breakages automatically. The key to success is robust testing, as it cuts the manual footprint significantly. This does mean we are quite judicious with selecting dependencies. It isn’t all that complicated when everyone is following best practices most of th…

I mean this seriously: congratulations on working someplace that has such rigorous requirements that you are able to write a comprehensive test suite that doesn't get completely rewritten every month or so. I guess because I enjoy working in startups, the cost I have to pay is that "requirements" are spelt "fever dream" and the "acceptance criteria" field in Jira is often just "." (because it's a required field, donchano)

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

#120

Post by barbazoo »

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

I am a seasoned programmer but whenever I deal with datetime objects I do my best with unit tests and then just hope none of these “edge” cases apply to us. Meaning: I have no idea really how it works under the hood.

Now at least there’s an LLM that might spot a bug every now and then so that’s nice.

Post reply on HN