Part of the problem is that it's hard to determine all the possible situations you could be in -- changing the time during a DST transition while using the Islamic calendar and so on. Formal methods are relatively inaccessible in general, but I wonder if you could make an easy-to-use verification tool specifically focused on date/time code.

You are right that it's near impossible and unpractical to test all edgecases. But your example goes into the wrong direction. Shouldn't you build your system completely agnostic of time interpretation changes? A DST transition is not actually changing the time. The bug here seems to be coming from system clock updates. I honestly also never thought testing against system clock updates. If I schedule something to happen in 10 seconds I never expected the system clock might be shifting backwards and 10 seconds might become minutes or more. But that should be so super rare.

What is a realistic code example that might have problems with system clock updates?

Not all parts of a system can be independent of changes to how time is interpreted or displayed. E.g. in a calendar: what happens to the time of a recurring meeting after a DST transition? What if participants are in different time zones with different DST rules?

But as long as you only need to track time for dealing with time intervals in an abstract fashion, you can get away with a nice continuous and monotonous scalar representation of timestamps.

This is why you should be using the system's monotonic clock source; they steadily increase and never shift backwards or forwards. They aren't, however, guaranteed to have any relation to real time between two measurements.

There is plenty of code that has problems with time shifts, simply look at how often software crashes or misbehaves when there are leapseconds. Cloudflare experiences some of their code crashing because over a leap second, the time a request took suddenly became negative.