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

21–30 of 151 posts

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

#21

Post by stavros »

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 before I can write something that serves my purpose.

For the datetime library, specifically, I'm switching to whenever for everything, because I've been bitten by conversions and naive/aware datetime confusion too many times.

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

#22

Post by vjerancrnjak »

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 all of the cases handled by Whenever are mostly when datetime is a long lived object, which I don't see a need for at all.

I use it purely for allowing tz input from client, convert to UTC immediately when it arrives, or, if I really need the tz, then save it separately, which is rare (one example is calendar, where tz should be stored, although probably not even next to every UTC but at the user level, another is workforce scheduling, where 8am-4pm or 8pm-4am can mean different things for different locations -- but this is no longer datetime, it's purely time in a timezone).

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

#24

Post by sgarland »

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?!

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

#25

Post by orthoxerox »

Mountain_Skies wrote: post #17
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.

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.

Shouldn't people wanting to maximize the hours of daylight after work work night shifts?

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

#26

Post by gjm11 »

Mountain_Skies wrote: post #17
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.

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

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

#27

Post by mvanbaak »

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.

As others stated, there are many rough edges and footguns in the stdlib. BUT ... in my (and yours apparently) opinion, it's a matter of knowing those edges/guns, and work with them. Like you, I also prefer to create my own code around those instead of bringing in some library that brings in their own foot guns and possibly sub-dependencies and and and...

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

#28

Post by globular-toast »

Mountain_Skies wrote: post #17
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.

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.

Clock noon already isn't the midpoint of the working day (9-5) for many people. I don't think anyone cares about it being when the sun is at its highest in the sky either. This isn't even something most people know, and it's not even true unless you live on the Greenwich meridian or n*15 degrees east or west. What matters is how early we have to get up in winter vs early we have to go to bed in the summer.

I've always been in favour of keeping the clocks at non-DST all year, but now I have a new proposal: keep them at DST and just hibernate in the winter. Work an hour or two less in the winter when it's miserable.

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

#29

Post by mr_mitm »

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.

Are you saying you never pull in dependencies? Why stop there, why not re-implement the std lib as well? Surely there is a sensible middle ground: If you only need a small part of a dependency, consider implementing it. If you make heavy use of a dependency and want to benefit of years if not decades of dedicated developers testing and maturing its code, with a large community who has already stepped in all pitfalls you might step into and collectively encountered all the edge cases, just use the dependency.

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

#30

Post by xandrius »

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.
Post reply on HN