Proposal: Monotonic Elapsed Time Measurements in Go

- Backward compatible. No API change.

- Naive, idiomatic and wrong use of the API automatically becomes naive, idiomatic and correct: Existing code that was using wall-clock time will now be using monotonic time when it should, and only when it should [1]

- No change to the memory footprint on 64-bit systems

- No change to the range of representable dates [2]

"No API change" means if for some reason it turns out to be a bad idea, they can still revert it and stay backward compatible (though of course, the documentation will mention how monotonic times are used to calculate better time differences and that would no longer be true after a revert).

Very impressed with the extensive survey of existing code which didn't find a single case where the change would cause an issue.

[1] Except when a user got out of their way to calculate a time difference in a non-idiomatic way.

[2] The range is only restricted when monotonic time information is present, which cannot sensibly be the case outside the restricted range.

Now whilst the author acknowledges Go can't rely on systems to smear leap seconds it was hopelessly naive to think they could in the first place.

    I hoped that the trend toward reliable, reset-free computer clocks would
    continue and that Go programs could safely use the system wall clock to measure
    elapsed times. I was wrong. Although Akamai, Amazon, and Microsoft use leap
    smears now too, many systems still implement leap seconds by clock reset.

But apparently allows them to change the semantics of those types. I am somewhat dubious about this. The point of the substantial appendix is to demonstrate that the change in semantics is safe in existing code, but it only looks at a subset of existing code. It's still possible that someone out there has made assumptions which will now be invalid, and their code will be broken by this change.

Spot on! But it's not as if they're unrelated - there is a deterministic formula for converting monotonic clock time to wall clock time, taking into account everything from leap seconds, via the calendar, to leap years.

The problem is that today's systems conflate the two kinds of time. The proposed solution here is to treat them as completely separate, which seems to me almost as great a mistake as treating them as the same.

What i'd like to see is:

1. Computers keep time using a monotonic clock, based on TAI [1].

2. When the local clock drifts from a master clock, it is corrected by slewing, ie making the local clock run slightly faster or slower for a while until it is back in sync with the master clock (as NTPD does now).

3. Computers keep track of the times of leap seconds, obtained via NTP or the tz file or whatever.

4. To convert from a TAI time to a wall clock time, the time is first converted to UTC by applying the leap seconds, and then converted to a human-readable date using the calendar.

Essentially, i want to move the handling of leap seconds from the clock to the formatting. If you can do this, the whole question of the impact of leap seconds on time measurement goes away.

It's still not perfect, because although the clock is monotonic, it doesn't always run at the most accurate possible rate: during slewing, it is deliberately deviated from this. You could solve this with another layer of indirection: run the clock at the best estimate of the true rate, and then keep track of drift over time, so that when converting to a wall clock time, you first apply drift correction, then leap seconds, then the calendar. Essentially, you're formally recognising the separate existence of local and global clocks.

You could potentially even change the drift correction retrospectively, so that a given local time would map to different wall clock times at different computation times. That starts to get pretty weird, though.

[1] https://en.wikipedia.org/wiki/International_Atomic_Time