[vjerancrnjak]

Does someone know when these performance issues matter? My understanding is that datetime is a shortlived object, you wouldn't want thousands of datetime objects all over the codebase.

Almost all of the time UTC is enough, if I need to filter/bucket/aggregate by some range, I can reach for datetime with tz for these filter/bucket/aggregate criteria, convert them to UTC and on continues `int` comparison.

I'd imagine all of the cases handled by Whenever are mostly when datetime is a long lived object, which I don't see a need for at all.

I use it purely for allowing tz input from client, convert to UTC immediately when it arrives, or, if I really need the tz, then save it separately, which is rare (one example is calendar, where tz should be stored, although probably not even next to every UTC but at the user level, another is workforce scheduling, where 8am-4pm or 8pm-4am can mean different things for different locations -- but this is no longer datetime, it's purely time in a timezone).

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