Make Clock.System() replaceable / mockable

Instead of injecting a Clock in every single function or class that uses the usual approach of LocalDateTime.now(), consider adding a way to replace the System clock instance if one wants to.

This would make classes that depend on the abstract context of now easily testable, and idiomatic, as we wouldn’t need to inject it everywhere just for the sake of testing.

I’m happy to provide a pull request for this possibility

[kluever]

JodaTime has similar functionality (DateTimeUtils.setCurrentMillisFixed(long) and friends) and it’s been a nightmare in large code systems. If some how one of your dependencies manages to use this in production, you’re going to have a really bad time. We went as far as using Error Prone to prevent non-test code from using these APIs.

If you want to control the value of “now”, then use dependency injection and inject a Clock into your system under test.

Static mutable state is almost always a bad idea.

[dkhalanskyjb]

Looks like the consensus is against the static setter idea, so closing the issue. The lesson from this discussion for us, the library writers, is that people do want to test their code using a mocked Clock.System. In practice, this means that we should strive to keep the surface area of the system-dependent subset of our API small, attempting to present as much functionality as is reasonable using pure calculations that never need to be mocked. Thank you all for the discussion!