Proper unit test mocking for timezone aware DateTime objects

Does anyone have any experience with unit testing modules that need to be tested using DateTime objects with different timezones without having a real timezone database?

I am having trouble understanding how I would mock the timezone database in a way that would allow using methods such as!(Date.t, Time.t, Calendar.time_zone, Calendar.time_zone_database) without failing since the timezone database is not available.

Never tried what you need but I’d think that mock or patch will do the job.

1 Like

I know mock, but I don’t know how to mock a timezone database with it.

I don’t want to mock the functions I am calling, because I want to assert that the timezone conversions are taking place in the modules I am testing.

Intuitively, I’d say just inspect Elixir’s source and see which timezone functions it uses when a timezone database is supplied?

Here’s what Elixir itself does when ultimately it gets down to calling a function from the timezone module: elixir/datetime.ex at 1a1eda52b46e37b0c77835e374c16ec64bb5c638 · elixir-lang/elixir · GitHub

Basically it calls its time_zone_periods_from_wall_datetime/2 function (first argument is datetime, second argument is a timezone).

Another example in Elixir itself is how such a timezone database can be faked. Here: elixir/fakes.exs at 1a1eda52b46e37b0c77835e374c16ec64bb5c638 · elixir-lang/elixir · GitHub

The link is to the above function but the entire module should be looked at.

You can combine that knowledge with either mock or patch so you have a local offline fake timezone database.


Just now saw your edit but it doesn’t change much. You can still make your mock respect timezone offsets.

Alternatively, I think you can just use a proper timezone database and instruct it to not do network requests.

tz has very configurable behaviour on when (or if?) to do automatic updates.

Here’s a link to the docs of tzdata that show you how to disable automatic updates.


Thank you! I’ll take a look and share the results

Using past datetimes on non disputed regions should give you a rather stable timezone definition.

If you still need more control then you can use Mox with the time zone database behaviour and mock that.