[crazygringo]

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?

[vjerancrnjak]

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.

[crazygringo]

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.

[vjerancrnjak]

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

[crazygringo]

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.

[vjerancrnjak]

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.