For testing purposes it is neat to overwrite the clock of UTCInstant. Currently, the used clock is static, which brings its various problems with it. Also the function setClock overwrites the clock for all future instances, which might lead to unexpected behaviour in case of forgotten resetClock. The latter can be prevented by using the proper Disposable feature of the UTCInstant class.
However, we should overthink the architecture and discuss the issue here, rather than in #215 since it does not pose an immediate risk and should no prevent he PR from merging (it only appears in unit-tests and integration-tests).
For testing purposes it is neat to overwrite the clock of UTCInstant. Currently, the used clock is static, which brings its various problems with it. Also the function
setClockoverwrites the clock for all future instances, which might lead to unexpected behaviour in case of forgottenresetClock. The latter can be prevented by using the properDisposablefeature of theUTCInstantclass.However, we should overthink the architecture and discuss the issue here, rather than in #215 since it does not pose an immediate risk and should no prevent he PR from merging (it only appears in unit-tests and integration-tests).