ps yes, you can implement n timers using a single underlying timer, but that of course requires even more book keeping, which was the point of my comment in the first place.

The two problems are almost exactly the same if you just use a time frame that does not change (permanent daylight savings, or never daylight savings)

The "almost" makes it sound trivial but hides complexity, e.g. around leap seconds.

https://en.wikipedia.org/wiki/Leap_second

Leap seconds are a problem too, but in entirely different settings, and in a way that is much better encapsulated in the software engineering world. I personally think the world would be better off without them, and that we should just let the clock/calendar drift back and forth, and in the long term off, true midnight. Outside of navigation and astronomy and a few other highly specialized fields, this has no meaningful impact, and would vastly simplify automated time recording. But it's a decision that has to be made globally, not nationally or locally, and requires a LOT of coordination to get right.

It is also fundamentally different in nature, in that leap seconds never create duplicate times in the time sequence. Leap seconds are changes to the sequence of the underlying elapsed time sequence; DST changes are not, but only change the representation and use of time values.

> At the risk of being pedantic. No, these are not the same.

Absolutely agree and that was my point in the comment you replied to.

If you want to measure elapsed time you should not involve absolute time measures because then you will not need to think about leap seconds or DST changes.