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

51–60 of 151 posts

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

#51

Post by mark-r »

raverbashing wrote: post #39
EdwardDiego wrote: post #18

Earlier quoted context omitted.

There are so many footguns in the datetime lib. That's why I use a Flake8 plugin to prohibit especially egregious footguns. https://github.com/jkittner/flake8-ban-utcnow

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.

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

#52

Post by brookst »

xandrius wrote: post #30
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.

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.

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

#53

Post by michaelt »

dmos62 wrote: post #46
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.

Curious about examples of projects being killed by dependencies.

While I've never seen a project killed by dependencies, I've certainly seen projects stuck on treadmill of constant dependency updates.

You know, they import 5 libraries, each of which imports 5 more libraries, each of which imports 5 more libraries, and suddenly they're buried in 'critical' updates because there's a denial-of-service bug in the date parser used by the yaml parser used by the configuration library used by the logging library used by the application.

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

#54

Post by brookst »

scott_w wrote: post #48
mvanbaak wrote: post #35

Earlier quoted context omitted.

The "lib" one needs for date time functions is as good as non-existent. But yeah, you will have to create tests for the codepath, instead of relying on the tests the library maintainers create.

Given the list of issues (most of which I had never heard of) that the library author describes with datetime, I think I trust his tests over the ones I’d write. Given how many tests I see fail on 29th February at the companies I’ve been at, I don’t trust my colleagues’ tests either!

In a previous job where we had complete hell with an internal datetime lib under ambiguous ownership, a colleague joked that the original authors had taken early retirement when they turned 2,147,483,647 years old.

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

#55

Post by ljm »

sgarland wrote: post #24
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.

You are a sad minority, IME. I’m right there with you. I extended the uuid library to generate UUIDv7, based off of the RFC. It’s pretty easy to implement, as it turns out. Overruled, because “we don’t want to have to maintain additional code.” As if the ABI for bitshifts is going to change?!

There’s an out of sight, out of mind mentality with dependencies.

As long as there is a conscious decision to build or ‘buy’, it’s fine. I think some people can be a little too careless with adding dependencies though, not realising they can have an equal if not greater maintenance burden.

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

#56

Post by xandrius »

raverbashing wrote: post #37
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.

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.

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

#58

Post by brookst »

layer8 wrote: post #44
snvzz wrote: post #12

A tangent, but I hope the world gets its shit together and gets rid of DST. I am currently enjoying DST-free life in Japan, and feel that people around the world deserve to get this much respect from their own official clocks.

I would wish for that as well, but it’s unlikely to happen. In the EU for example, some countries would be on the losing side, either by getting “bad” hours or by having to move to a different time zone than their neighbor, which has significant economic consequences. Such countries won’t agree to a DST abolishment that disadvantages them. And for program code, it wouldn’t really help as long as it’s still expected t…

I don’t understand how eliminating DST would impact economics of neighboring countries… today they both change clocks, tomorrow they don’t. What changes?

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

#59

Post by brookst »

gjm11 wrote: post #26
Mountain_Skies wrote: post #17

Earlier quoted context omitted.

Almost everyone wants to get rid of the twice annual clock changes but are nearly evenly divided on if DST should be permanent or cease to exist. It's a strange artifact of wanting clock noon to be the midpoint of the workday but also wanting to maximize the hours of daylight after work.

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.

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

#60

Post by ljm »

dmos62 wrote: post #46
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.

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 kind of deliberate approach behind the scattershot application of packages with duplicated purposes.

(picking on JS is perhaps unfair but it’s probably the most egregious example of dependency hell)

Post reply on HN