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

141–150 of 151 posts

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

#141

Post by crazygringo »

vjerancrnjak wrote: post #140
crazygringo wrote: post #138

Earlier quoted context omitted.

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…

I genuinely don't understand what you're talking about.

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

No I didn't. I literally said "You need to store things permanently with the timezone". Obviously lunch at 12 belongs to a specific timezone.

> Yet again, no need for long lived datetime.

You keep saying this. I don't know where you're getting it from. You need to store these things in databases. If my calendar goes 2 years in the future, these datetimes live for 2 years at least.

It sounds like you're arguing that datetime libraries don't need to exist. I'm genuinely baffled. That feels as nonsensical to me as saying that floating point numbers don't need to exist. Long-lived datetimes are a commonly required thing in anything regarding calendars or scheduling. If you don't believe there is a genuine use case for this, I don't know what to tell you.

I was trying initially to provide you with a basic answer to what seemed to be a genuine question, but I can't help you anymore.

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

#142

Post by vjerancrnjak »

crazygringo wrote: post #141
vjerancrnjak wrote: post #140

Earlier quoted context omitted.

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…

I genuinely don't understand what you're talking about. > You’ve also stated you want to ignore the timezone and display 12 in whatever tz. No I didn't. I literally said "You need to store things permanently with the timezone". Obviously lunch at 12 belongs to a specific timezone. > Yet again, no need for long lived datetime. You keep saying this. I don't know where you're getting it from. You need to store these thi…

> You don't want your scheduled lunch to move from 12 to 1 because it's DST.

Yes, therefore you won't store lunch as `datetime` you will store it as `time` and on "render" you will make sure it is 12th hour for localized datetime. Look at RFC 5545. If you move from Japan to Romania, you'll again on render (with stored 12 as `time`) display lunch at 12th hour. The only thing one stores is daily occurrence and 12th hour, with careful interpretation what is a boundary of a day and what is 12th hour. `datetime` does not help, similar to how it does not help with DST issues for workshifts (which are again `time`).

> If my calendar goes 2 years in the future, these datetimes live for 2 years at least.

Why would you materialize recurring events, if you move from Vietnam to Spain, how will all those lunches become Spain lunches? Just recompute the whole future? Sounds like a mistake of storing long-lived objects that should have been replaced with computation with short-lived ones.

> It sounds like you're arguing that datetime libraries don't need to exist.

Steelman me. 2 individuals tried to expand to include you into discussion, you seem to go in the other direction every time.

I am not implying that. I'm implying that I don't understand the performance implications, given that I'd expect to work with efficient UTC most of the time, with only a constant amount of stuff going from datetime-with-tz to UTC. I cannot imagine a case where you'd abundantly store datetime-with-tz, it sounds like a mistake.

My own impression is that majority opinion is that going from datetime-with-tz to UTC and then doing comparisons, filtering, bucketing, aggregating is somehow flawed? If I need 24 hour buckets, I can do it through UTC, if I need "daily" buckets, I can still do it through UTC -- with short-lived datetime-with-tz to UTC computation, yet UI will still have to deal with 23/25 hour days, `datetime` does not solve that problem. I understand monthly buckets, still easy to do through UTC with short-lived conversion. (go from datetime-with-tz to UTC that's used to filter/group entries in db)

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

#143

Post by freehorse »

akerl_ wrote: post #122
freehorse wrote: post #43

Earlier quoted context omitted.

To be fair, comment^^ actually said choice between "reading docs/changelogs carefully, implementing functions", and "adding an extra dependency" which is what comment^ answers to, which to me actually sounds like that the added dependency comes in place of "reading docs/changelogs carefully". I think it matters a lot how much one can trust a 3rd party library, how much it is used, how much it is maintained etc. Moreo…

How could it possibly be true that libraries that are so commonly used that you consider them “the standard” are so infrequently used as to be a “very small minority” of libraries people actually use?

I am not sure I understand the comment. I used pandas as an example of sth I frequently encounter when dealing with python code dealing with data frames. Is it not commonly used? What’s your argument here, I am genuinely asking.

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

#144

Post by crazygringo »

vjerancrnjak wrote: post #142
crazygringo wrote: post #141

Earlier quoted context omitted.

I genuinely don't understand what you're talking about. > You’ve also stated you want to ignore the timezone and display 12 in whatever tz. No I didn't. I literally said "You need to store things permanently with the timezone". Obviously lunch at 12 belongs to a specific timezone. > Yet again, no need for long lived datetime. You keep saying this. I don't know where you're getting it from. You need to store these thi…

> You don't want your scheduled lunch to move from 12 to 1 because it's DST. Yes, therefore you won't store lunch as `datetime` you will store it as `time` and on "render" you will make sure it is 12th hour for localized datetime. Look at RFC 5545. If you move from Japan to Romania, you'll again on render (with stored 12 as `time`) display lunch at 12th hour. The only thing one stores is daily occurrence and 12th hou…

You seem to be deliberately misunderstanding me, so I don't know what to tell you. Again, I tried to help explain it to you, but you are refusing to acknowledge that people really do store events as future datetimes attached to a timezone, not just as local times, and I don't know why you continue to insist otherwise.

Good luck.

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

#145

Post by ljm »

MrJohz wrote: post #69
ljm wrote: post #60

Earlier quoted context omitted.

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…

I used a bad example with the Date API, except that, say, using moment or date-fns and sticking to it would be better than jumbling them up. If you’re going to do a migration from one to the other then it has to be committed to.

Dependencies themselves can’t be good or bad. They only acquire that property in the context of the dependent codebase. And a codebase that you can’t spin up from scratch or easily grok because of its approach (or lack thereof) to dependencies is almost certainly on the bad end of the spectrum.

I’ve seen this destroy some python codebases internally. In fact, my choice of a JS example was unfair because it becomes an absolute shitshow in python once you have dependencies and transitive dependencies with very tight version constraints.

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

#146

Post by pseudalopex »

snvzz wrote: post #139
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.

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

This is a coordination problem. DST was the solution many societies found.

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

#147

Post by ok_dad »

stavros wrote: post #111
ok_dad wrote: post #107

Earlier quoted context omitted.

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.

Well you know nothing about me so screw off.

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

#148

Post by stavros »

ok_dad wrote: post #147
stavros wrote: post #111

Earlier quoted context omitted.

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

Well you know nothing about me so screw off.

You felt you knew enough about me to tell me to learn my job, so I figured you'd be open to similar feedback.

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

#149

Post by vjerancrnjak »

crazygringo wrote: post #144
vjerancrnjak wrote: post #142

Earlier quoted context omitted.

> You don't want your scheduled lunch to move from 12 to 1 because it's DST. Yes, therefore you won't store lunch as `datetime` you will store it as `time` and on "render" you will make sure it is 12th hour for localized datetime. Look at RFC 5545. If you move from Japan to Romania, you'll again on render (with stored 12 as `time`) display lunch at 12th hour. The only thing one stores is daily occurrence and 12th hou…

You seem to be deliberately misunderstanding me, so I don't know what to tell you. Again, I tried to help explain it to you, but you are refusing to acknowledge that people really do store events as future datetimes attached to a timezone, not just as local times, and I don't know why you continue to insist otherwise. Good luck.

I did not insist people do not store future datetimes with offsets. I wondered if it's a mistake. People who store future datetimes with tz obviously have to parse all of them and would need performance, but my opening statement was questioning when this is actually necessary, as it looked rare to me.

RFC 5545 introduces floating time to -- I assume -- avoid this silliness, so that your lunch is actually forced to be rendered at 12 regardless of tz.

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

#150

Post by ok_dad »

stavros wrote: post #148
ok_dad wrote: post #147

Earlier quoted context omitted.

Well you know nothing about me so screw off.

You felt you knew enough about me to tell me to learn my job, so I figured you'd be open to similar feedback.

True, my bad. I apologize. I’m impressed by your grace with this comment.
Post reply on HN