> The wall clock is for telling time; the monotonic clock is for measuring time.
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.
> there is a deterministic formula for converting monotonic clock time to wall clock time
I think "deterministic" is not really right here, since you can only convert monotonic times in the past, not the future, and only after you have been given the (completely arbitrary) leap second data. If you call that "deterministic", then what isn't?
> The proposed solution here is to treat them as completely separate
Did you read the proposal? Because the Go folks are essentially trying to present a single, unified API for both, whereas lots of comments here on HN are suggesting the separate-API approach instead. Also, the Go folks specifically call out Google's efforts to eliminate the leap second problem from their systems and how/why it hasn't caught on outside of the big players. Can you compare your proposal to Google's time handling solution? Does it suffer the same problems mentioned in the the post?
> I think "deterministic" is not really right here, since you can only convert monotonic times in the past, not the future, and only after you have been given the (completely arbitrary) leap second data. If you call that "deterministic", then what isn't?
You're right that the "deterministic" formula doesn't extend all the way into the future. If you believe Wikipedia [1], then leap seconds are added at two points in the year, and we've always had about six months' warning, so there's a window of about six to twelve months ahead where all the leap seconds are known. I don't think it's useful to get into what "deterministic" means, but you're quite right that you can't reliably convert monotonic times to human times, or vice versa, beyond that window. I'm not sure how much that matters.
> Did you read the proposal?
You're not supposed to ask that! But yes, i did.
> Because the Go folks are essentially trying to present a single, unified API for both, whereas lots of comments here on HN are suggesting the separate-API approach instead.
No, they are presenting a single type which conceals both kinds of time. This will lead to surprising behaviour if you ever rely on both kinds. For example:
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