It seems to me that you are mostly arguing about what kind of time to use for a given business problem here. This is actually an interesting problem, but it is

It seems to me that you are mostly arguing about what kind of time to use for a given business problem here. This is actually an interesting problem, but it is a business problem. For example where I live trains will have a 1h delay (sometimes there are buffers that you can use to reduce the delay, or you cancel trains that anyway only run in the time window that is missing) when “springing forward” and will take a 1h break in the middle of the night when “falling back.” The schedule itself doesn’t change. Seems weird to me, but it is how the business rule is. But what if the business rule is to use wall clock time? And that is actually a sensible choice for things like concerts or dinner appointments in a calendar. When you use wall clock time (I assume that is what you mean when you call it local time) in example 4 you choose > local time + take first occurrence on spring offset change which is _one_ possible way to handle duplicate wall clock times; wall clock times are underspecified which you implicitly admit by choosing the first occurrence. So it _is_ a data type issue, unless you define the wall clock time data type to contain the occurrence number (e.g. something like `2022-10-30 02:32 II`). To me that’s not a wall clock time but a wall clock time _with occurrence_ (or whatever name you want to give it) and it’s probably not a concept the user will know, so it needs some UX tweaks (e.g. hide the occurrence when there are no duplicate times and when there are notify the user about the ambiguity, offer a default and explicitly state it, maybe allow to change it to the 2nd occurrence, or maybe disallow duplicate times and ask for another time). Another problem is that when switching forward there are holes in the time line, but that is easier to solve (it’s an invalid input).