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

61–70 of 151 posts

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

#61

Post by filoeleven »

stavros wrote: post #36
globular-toast wrote: post #32

Earlier quoted context omitted.

> 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 is much more heavily tested and documented than any 3rd party library will be. You initially said you write your own code instead of using libraries, I replied to that, and now it's that you use the stdlib instead of libraries. I won't argue against shifting goalposts.

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.

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

#62

Post by stavros »

filoeleven wrote: post #61
stavros wrote: post #36

Earlier quoted context omitted.

> The stdlib is much more heavily tested and documented than any 3rd party library will be. You initially said you write your own code instead of using libraries, I replied to that, and now it's that you use the stdlib instead of libraries. I won't argue against shifting goalposts.

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 all other code remains the same, otherwise there would be no point to writing a library, as it would offer nothing over `datetime`.

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

#63

Post by jessekv »

mark-r wrote: post #51
raverbashing wrote: post #39

Earlier quoted context omitted.

Honestly yeah who in tarnation created that function and called it utcnow These things are really frustrating

Yeah, utcnow is completely broken. They should have fixed it when they created datetime.timezone.utc, but they didn't. The recommendation is to use datetime.datetime.now(datetime.timezone.utc) instead. utcnow should be deprecated and eventually removed.

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)

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

#64

Post by foolfoolz »

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.

this is a great idea if you want to slow down your project. most projects start with few rules and “best practices” like this. everyone is free to pull in dependencies as needed. because they are needed. but then once the project grows larger, those who have been around longer want to reverse course and gatekeep dependencies. but this is the opposite of what helped the project grow initially. and later contributors have a harder time making similar progress because they have to fight to add basic libraries. ensuring that efficiency per engineer goes down

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

#65

Post by thijsvandien »

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.

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

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

#66

Post by crazygringo »

brookst wrote: post #52
xandrius wrote: post #30

Earlier quoted context omitted.

Creating from scratch also creates hidden debt, it's just moved onto yourself. Especially when working with dates and timezones.

I cannot imagine having the spare time to invest in building date/time foundations and maintaining them through changes to DST timing and country/time zone changes. The only crazier idea I can think of is implementing character encoding conversions myself.

Seriously.

Nobody needs a package for "left-pad", which is the most infamous example.

But there are a lot of areas where it's not a good use of your time to reinvent the wheel. There's no moral virtue in writing everything yourself. And popular packages have gone through a more bug-finding and bug-fixing than your personal code probably ever will.

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

#67

Post by maleldil »

jessekv wrote: post #63
mark-r wrote: post #51

Earlier quoted context omitted.

Yeah, utcnow is completely broken. They should have fixed it when they created datetime.timezone.utc, but they didn't. The recommendation is to use datetime.datetime.now(datetime.timezone.utc) instead. utcnow should be deprecated and eventually removed.

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.

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

#68

Post by crazygringo »

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 countries change DST etc.

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

#69

Post by MrJohz »

ljm wrote: post #60
dmos62 wrote: post #46

Earlier quoted context omitted.

Curious about examples of projects being killed by dependencies.

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 using a sensible dependency.

Some problems simply require using the right tools. They aren't necessarily hard, but they will be if you try to hammer a nail in with a screwdriver. The Date API, and to a certain extent Python's datetime module, are screwdrivers for a nail-shaped problem.

The rest of your example seem to have more to do with bad dependency practices than using dependencies in the first place. If you are going to include a dependency, think about it, consider whether it's worth it, document that decision, and then consistently use that dependency. Just because you've seen projects use dependencies poorly doesn't mean dependents are bad by themselves.

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

#70

Post by jwilk »

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

Discussed on HN back then:

https://news.ycombinator.com/item?id=39417231 (147 comments)

Post reply on HN