[antonvs]

The point of the OP is that it changes calls to `time.Now` regardless of whether the code that's calling it uses your variable or not.

[Groxx]

I suspect that using a build tag (say `test`) and two function definitions (one that directly calls `time.Now()` and one test-only one that uses a mutable var) will optimize out to zero cost in the non-test case - last I fiddled with that, it was pretty good at consistently inlining trivial wrapper funcs like that.

[awesome_dude]

The compiler will only use _test.go files in the test build - so not an explicit build tag, but a built in one.

[Groxx]

That doesn't give you a way to exclude conflicting code, unfortunately, so you can't provide an optimal one for non-test code with it.

And stuff like `func SetTime(...)` in a _test.go file only works for tests in that same package, because other packages don't compile that _test.go and won't have that function defined.

[awesome_dude]

I'm not sure that we are on the same page

Are you saying that you want multiple build tagged files each with a different implementation of the function, all in the same package? (eg. windows, linux, arm)

I mean, the example given by the GP is two implementations in the same package, the standard library version is used in the prod file and the test implementation in the test files - the _test.go is the (implicit) build tag

Or do you have something else in mind?