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

131–140 of 151 posts

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

#131

Post by MrJohz »

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…

It typically takes me maybe an hour to update my dependencies? I run type checks and e2e tests as part of that to have a relatively high degree of confidence that nothing has been broken. Also splitting the change into multiple steps (i.e. do minor/patch upgrades first, check nothing's broken, run a major upgrade, check nothing's broken, etc) means it's fairly to see where something is causing problems and needs to be handled more carefully.

I do this typically every couple of weeks, and it takes up almost no time at all in comparison to time spent on other work. Someone needs to review the eventual PR created, but that's also typically fairly easy. NPM makes this all very easy to do. In Python I've used tools like PDM or uv to handle dependencies similarly.

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

#132

Post by throwaway2037 »

kelseydh wrote: post #130

A big revelation for me in solving so much timezone insanity came from realising that timezones should be expressed as locations rather than zones. Avoid general terms like "Pacific Standard Time" and stick to location-specific ones like: "Vancouver/Canada". The latter is how people expect their time to work, and correctly handles whatever quirky choices jurisdictions choose to do with their time.

In my experience, all worthy date/time libraries use time zone IDs from the "tz database". Ref: https://en.wikipedia.org/wiki/Tz_database

Searching the list here: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones

I cannot find an entry for "Pacific Standard Time" nor "Vancouver/Canada", but I can see: "America/Vancouver".

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

#133

Post by throwaway2037 »

Reading this post and comment section makes me shake my head. This looks like a near clone of Java JSR-310 (new date/time APIs), which was headed by the original author of Joda Time (Stephen Colebourne). Java 8 (and JSR-310) was released in 2014 -- 11 years ago(!). Amazingly, Python has suffered with their date/time libs this whole time with very little concerted effort to create new date/time APIs in the standard library. It's pathetic. I know I will be downvoted for this post, but I don't care. The Python standard library has so many of these awful weaknesses that other languages handle better. Except for machine learning R&D, I never recommend to use Python for any enterprise project except trivial ones. You are walking into a double trap of (1) weak types and (2) weak standard library.

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

#134

Post by raverbashing »

MrJohz wrote: post #131
crote wrote: post #108

Earlier quoted context omitted.

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…

It typically takes me maybe an hour to update my dependencies? I run type checks and e2e tests as part of that to have a relatively high degree of confidence that nothing has been broken. Also splitting the change into multiple steps (i.e. do minor/patch upgrades first, check nothing's broken, run a major upgrade, check nothing's broken, etc) means it's fairly to see where something is causing problems and needs to b…

Yes, in python only with modern tools this is somewhat feasible

And you still have upgrades that break interfaces and such

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

#135

Post by JimDabell »

kelseydh wrote: post #130

A big revelation for me in solving so much timezone insanity came from realising that timezones should be expressed as locations rather than zones. Avoid general terms like "Pacific Standard Time" and stick to location-specific ones like: "Vancouver/Canada". The latter is how people expect their time to work, and correctly handles whatever quirky choices jurisdictions choose to do with their time.

The rule of thumb is: Use UTC to record when things happened (e.g. logging), use local time + timezone name (e.g. `Europe/London`) to schedule things for the future (e.g. meetings).

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

#136

Post by matsemann »

jethkl wrote: post #38
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…

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

It's basically what happened in Java. Everyone used jodatime, and they took great inspiration from that when making the new standard time api for java 8.

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

#137

Post by therealpygon »

crazygringo wrote: post #97
vjerancrnjak wrote: post #90

Earlier quoted context omitted.

But lunch is 12 in time, not in date. You have to decide, with short lived datetime what the desired outcome is for today. So you would not store that in UTC but just in time. But yes, I’m ignoring the standard of calendar formats , maybe they are simpler . I read through the article listing all the weirdness of other datetime libraries and I’d say many were covering cases where you behave that timezoned datetime is…

No, my weekly lunch is at 12 every 7 days across a variety of dates. The number of hours between each lunch changes due to DST.

I’m not sure I understand your disagreement and then expressing what appears to be exactly what they said; that an appointment happens at a specific time of day, not as a recurrent datetime that needs to shift with DST.

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

#138

Post by crazygringo »

therealpygon wrote: post #137
crazygringo wrote: post #97

Earlier quoted context omitted.

No, my weekly lunch is at 12 every 7 days across a variety of dates. The number of hours between each lunch changes due to DST.

I’m not sure I understand your disagreement and then expressing what appears to be exactly what they said; that an appointment happens at a specific time of day, not as a recurrent datetime that needs to shift with DST.

I don't understand what you don't understand?

If you have a recurring lunch, it's always at the same local time interval, but not the same UTC interval, because of DST. Calculating with it requires datetimes, not just times or UTC from the start, contrary to who I was responding to. What is unclear about that?

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

#139

Post by snvzz »

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.

>but also wanting to maximize the hours of daylight after work.

Maybe adjust the work schedule to e.g. start at 8 instead of 9?

Rather than mess with the actual clock.

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

#140

Post by vjerancrnjak »

crazygringo wrote: post #138
therealpygon wrote: post #137

Earlier quoted context omitted.

I’m not sure I understand your disagreement and then expressing what appears to be exactly what they said; that an appointment happens at a specific time of day, not as a recurrent datetime that needs to shift with DST.

I don't understand what you don't understand? If you have a recurring lunch, it's always at the same local time interval, but not the same UTC interval, because of DST. Calculating with it requires datetimes, not just times or UTC from the start, contrary to who I was responding to. What is unclear about that?

Lunch as a recurring event in this particular setting is defined as a daily (recurrence type enum) event occurring at 12 (time).

You’ve also stated you want to ignore the timezone and display 12 in whatever tz.

So if my interface is all events between start_utc and end_utc I will construct local datetime and can convert it to UTC and send it to frontend.

The problem with hours that don’t exist in a tz/DST needs to be dealt with separately and given Whenever raises an error and datetime does not is good. In the article that’s one of few that applies, others only exist if you have massive amounts of long lived tz datetime objects.

Yet again, no need for long lived datetime. The problem you picked is time + occurrence.

Imagine a work shift from 23-8 , DST might turn it into less or more than 9 hours. Library does not help as you have to explicitly decide what to do. To avoid the issue then you’d reinterpret user input as start time and duration. When constructing hours, you’d shortly reach out to datetime that is localized. This is again not a datetime problem as work shift is just time.

Showing data on a chart in localized time, one has to explicitly decide what to do with hours that don’t exist or are 2 hours long (visually). Having long lived tz datetime does not help.

Post reply on HN