Provide the ability to control the source of time

[chrisokuda]

I had been looking at this library as a library I could use to control the "current time" by controlling a "managed clock": https://hexdocs.pm/time_machinex/readme.html#content

However, this library is not compatible with TimeX due to the overlap in domain.

• Be able to use the clock as usual when in :dev or :prod, for example, but when in :test the clock would behave differently (or have a flag to the now() function that uses the managed clock)
• Be able to freeze the clock and restart it
• Be able to set any arbitrary time in any TZ on the clock
• Be able to speed up or slow down time by a factor, such as 1 second per minute (slow by 60x) or 1 hour per second (speed up by 3600x)
• Be able to provide a function to the managed clock that transforms the real-time clock into another time (maybe it would be "good enough" to provide a way to pass a function into the current now() function and then use that function to transform the clock, then I can just put transformations into the code where I want it and we wouldn't need to have other methods to control a managed clock?)

Thanks so much for the nice library and for considering this proposal.

[bitwalker]

@chrisokuda In general it can be very difficult to control time for testing purposes like this, as you need a high degree of cooperation from all of your dependencies and your own code, this can include NIFs which access the system time from native code. I'm not sure this there is much Timex can do directly to make that easier. In general I think you'd need something that manipulates the BEAM's perception of time directly. Timex defers to Erlang and Elixir standard library APIs for obtaining the current date/time, as well as system time for durations and such, so you'd ideally want to exert control on those APIs directly, perhaps via mocks.

That said, if there are particular things Timex needs to do differently to better interoperate with tools that do manage the system time somehow, I'm open to making changes. In theory, Timex could call system APIs through a behavior that can be mocked, at least when calling APIs that are sensitive to the current system time. I'd like for there to be some kind of community standard for such an interface though, so we're not all going about it in different ways. @lau might have some thoughts on this.

As an aside, you can already set the local timezone, e.g. Application.put_env(:timex, :local_timezone, "America/New_York"), so for anything that depends on the local timezone, that capability is available to you at least.