[crazygringo]

In my experience it's for calendar-related stuff. You need to store things permanently with the timezone, especially for recurring events. You don't want your scheduled lunch to move from 12 to 1 because it's DST.

And so anything server-related with calendars will be making tons of these conversions constantly. And you can't cache things long-term in UTC because the conversions of future events can change, when countries change DST etc.

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