You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Based on the direction #12914 is heading, it looks like nearly all uses of time.Now+time.Since should be using time.XXX and time.SinceYYY instead (XXX and YYY yet to be determined), to use a monotonic clock in place of the wall clock.
Go 1.8 introduces time.Until. Uses of time.Until are likely just as wrong as uses of time.Since. Should we remove time.Until from Go 1.8, at least until we know what we are doing with monotonic clocks?
The text was updated successfully, but these errors were encountered:
Removing Until doesn't change the fact Since is still relative to Now(). If we were change Until to be relative to the new monotonic API, I think it would be more confusing. I'm not oppose to removal, though.
Since Until is just a commodity function, I agree that it shouldn't be added until we figure out what to do with monotonic clocks. Independently of whether Since is still broken or other factors, leaving this in would encourage the non-monotonic approach further and we wouldn't be able to change it later.
I'm slightly in favor of keeping it. Like @dsnet says, Since already exists and we can't change it, which means we'll need some new names anyway, and it'd be weird if we add Until later but with time.XXX types.
Based on the direction #12914 is heading, it looks like nearly all uses of time.Now+time.Since should be using time.XXX and time.SinceYYY instead (XXX and YYY yet to be determined), to use a monotonic clock in place of the wall clock.
Go 1.8 introduces time.Until. Uses of time.Until are likely just as wrong as uses of time.Since. Should we remove time.Until from Go 1.8, at least until we know what we are doing with monotonic clocks?
The text was updated successfully, but these errors were encountered: