This strategy fails for appointments during that hour where the clock goes back: they are ambiguous, can refer to two different moments in time.

That caveat aside: good.

▲

jagged-chisel 7 hours ago | parent | next [-]

I have yet to find a technological solution to this social problem.

Also, I have yet to encounter this problem. For personal events, I sleep during this time. For company events, we always avoid this time.

	▲	ncruces 7 hours ago \| parent \| next [-]
		I encountered it when I was design the scheduling back-office for a LED video wall a few years ago when those became economical for a shop to own and run 24/7. The customer probably never noticed if I even did it “correctly” or couldn't be bothered if I didn't, but I remember I was bothered by it: (1) ensuring continuity of programming during the gap when it jumps forward (2) solving the ambiguity when it went backwards. Because obviously they wanted to think in local time.
	▲	rjrjrjrj 5 hours ago \| parent \| prev \| next [-]
		I have, in the context of time series charts. Lots of back and forth with QA.
	▲	mulmen 7 hours ago \| parent \| prev [-]
		You're right that for the most part this is avoided by convention and scheduling time changes at quiet times of day. A bit contrived but consider you are a maintenance worker in a facility that uses isolated timekeeping devices. "Change the clock on the vault back one hour at 3:00am".

▲

rawling 7 hours ago | parent | prev | next [-]

Sounds like the quoted RFC would help here. Storing the offset would make it unambiguous which of the two moments was meant. Your business logic would have to figure out what to do when the offset no longer exists (honour the clock time or convert to the new timezone) or is nonsense. The geographical reference would help decide what to do if you're not in a single location.

▲

rini17 7 hours ago | parent | prev [-]

Humans would often fail such appointments too.