3 ms·

> 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

by kevhito 10y ago

> 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?

twic 10y ago
> 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: https://news.ycombinator.com/item?id=13574235 https://news.ycombinator.com/item?id=13574235 [1] https://en.wikipedia.org/wiki/Leap_second#Insertion_of_leap_seconds https://en.wikipedia.org/wiki/Leap_second#Insertion_of_leap_...

by kevhito 10y ago

twic 10y ago

> 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: https://news.ycombinator.com/item?id=13574235 https://news.ycombinator.com/item?id=13574235 [1] https://en.wikipedia.org/wiki/Leap_second#Insertion_of_leap_seconds https://en.wikipedia.org/wiki/Leap_second#Insertion_of_leap_...