[vjerancrnjak]

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

One case even pointed out datetime construction with an impossible hour.

[crazygringo]

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.

[therealpygon]

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.

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