Rule number one and the only rule about wall clock times is that they are display style only and must never be stored. Local times must use 24 hour format.
We don't typically care about this because we work 9-5 M-F, and daylight savings time conveniently happens at 2am on Sunday morning. But someone was told to come in at 2am this morning and couldn't actually do that because 1:59:59 became 3:00:00. How do you handle that? It's not a code problem, it's a business rules problem.
Data stored this way is basically telling that regardless of current UTC offset, locally on the clock there will be always the same time shown.
Display rules are saying how exactly this time will be displayed on the clock (i.e. locale, 12/24 hour format etc). Wall clocks usually do not show "am/pm" information, so the same time indeed may occur twice on them.
When the parent comment said "Wall clock times may occur twice", they meant between 2 and 3am when when leaving DST.
I believe they were referring to the fact that because of DST and other time adjustments, 24h wall clock times can in fact occur twice (or not at all, like this morning).
Few examples:
1. Local public transportation systems must commit to certain schedule of departures from every stop and make it unambiguous. This means that they have to always use local time in publicly communicated schedule, but plan the time table in UTC assuming that offsets will not change. Usually results in departures happening twice on the same time, requiring some extra resource planning.
2. Long-range trains and flights must (and usually do) operate in UTC, communicating arrival and departure times via display rules.
3. Shift planning in 24-hour working processes: offsets complicate the planning process and add unnecessary risk of breaking compliance, so they better be avoided and UTC must be used in combination with display rules.
4. Execution of scheduled jobs: depends on recurrence setup, for which display rules must distinguish between "once per day" (local time + take first occurrence on spring offset change) and "every 24 hours" (UTC + display times of occurrence).
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).
