time: mockable time support

[jmhodges]

With https://github.com/jmhodges/clock and the broader https://github.com/benbjohnson/clock API,
there's a desire for the timing systems in Go to be fakeable[1]. Using a fake clock
instead of time.Now directly is useful when testing code that stores timestamps, caches
data, etc.

The benbjohnson clock package attempts to make Ticker and Timer calls (as well as their
related AfterFunc and Sleep methods) work against a fake time that can be set and
updated in tests. However, it relies on some micro-sleeps and runtime.Gosched calls that
are obviously going to be flaky. But there is a desire to able to test code that uses
Tickers and Timers, not by adjusting the durations they work for (which can induce flaky
testing), but by adjusting when they think they need to wake up.

To do that, we seem to need more runtime magic to help developers out. In fact, it might
be best if a clock package like these lived in the stdlib so that it could be tied more
carefully and thoughtfully to the scheduler.

 [1] or "mockable", whatever language you prefer. The summary of this issue is to distinguish it from issue #5356.

[ianlancetaylor]

Comment 1:

I'm not entirely sure this is a good idea.  I'm also not sure what it would look like. 
If the goal is simply to provide Ticker and Timer calls for testing, I think that could
be done entirely independently of the time package, along the lines of the old
playground code.  The testing package would keep its own queue of events, and step
forward to the next event without actually waiting.

Labels changed: added repo-main, release-none.

[dvyukov]

Comment 2:

I am not sure playground approach will work in large apps. In playground we advice time
when the process in completely out of other work. But what if we have a goroutine in a
syscall/cgo, should we advice time? Or wait for it to return from syscall/cgo first?

[sougou]

Comment 3:

The main challenge we faced was related to the original code importing the standard time
package, which is not mockable. This forces the tests to also use actual clock time.
We've mostly managed to work around these. So, it's not a big issue now. But it's still
a nice-to-have.

[sougou]

Comment 4:

What if the time package accelerated the clock (just for the process) by an order of
magnitude? We can consider restricting this ability to the testing package.
There are still some downsides: it won't work for integration tests, but it may satisfy
the needs of simple in-process tests.

[jmhodges]

Any chance of something happening for this?

[jmhodges]

(I'm okay with hearing no! It's just an open cycle in my head I'm trying to clear out.)

[adg]

It's unlikely to happen any time soon.