Provide a behaviour for other third-party time zone database libraries?

[mathieuprog]

Timex adds time zone support only through tz_data currently. However, there are other time zone libraries, such as

• tz (mine) https://github.com/mathieuprog/tz
• time_zone_info https://github.com/hrzndhrn/time_zone_info

Each comes with differences in terms of reliability (latest tz_data is pretty bugged, see forum post, and crashes with RuntimeErrors for some datetimes), performance and technology.

It would be nice to give the user the ability to choose from the available time zone libraries. The time zone library author would have to implement a behaviour that timex provides. This will also make the code more clean, where we have an interface based on which we can plug the third-party time zone library.

[bitwalker]

I'm open to this, I've already internally refactored Timex to use its own internal timezone database facade, so supporting other libraries should be viable.

If someone is interested in pursuing this ASAP, I'd like to see a PR where Tzdata is not directly referenced anywhere in Timex, with some set of tests that exercise both tzdata and at least one other library (can be added to mix.exs as a test-only dependency).

[mathieuprog]

internally refactored Timex to use its own internal timezone database facade

This has been committed? What's the module name of the time zone db facade?

It will not be enough for Timex to retrieve the default time zone database of the app. That's because Timex requires functions to be implemented, so it should provide its own behaviour, as mentioned in the issue. For example, Timex requires a method zone_exists?, which is not part of the Elixir's time zone database behaviour. Consequently, Timex cannot just be satisfied with the default time zone database. What I suggest is that Timex takes a new config option, for example in case tz wants to be used:

config :timex, :timex_time_zone_database, TzTimex

I called it for example timex_time_zone_database because it requires a time zone database that must be compatible with Timex. Tz is a time zone database that works for DateTime but not for Timex because it lacks functions. TzTimex would be a new library I would create to provide all what Timex needs. I think at the moment it's just zone_exists? (might have missed some). It will also provide a function to retrieve the behaviour for Elixir DateTime, and Timex will call:

Calendar.put_time_zone_database(time_zone_database)

Note that the reason it was more simple with Tzdata is because they decided to implement zone_exists? and any future Timex need in the library itself. If we follow that new idea though, Tzdata will have to implement that behaviour, which means that Tzdata will no longer work with Timex without a minimum effort from the maintainers to implement the new behaviour.