4 ms·
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 c
by ascar 8y ago
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?
- gmueckl 8y agoNot 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.
- zaarn 8y agoThis 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.