TL;DR: The Elixir Core team is announcing a call for proposals to extend support for time zones in Elixir’s standard library.

The reasoning

Elixir’s relationship with dates times and calendars used to be bumpy. Fortunately, in the 1.3 release we got the built-in calendar types (DateTime, NaiveDateTime, Date and Time) with a thought-through and hopefully future-proof structure and interface. In the following releases, the number of defined APIs grew and the support for various features and algorithms increased.

Today, all the libraries (timex, calendar, ecto and more) use the built-in structs and define various algorithms using them, which means they are fully inter-operable and there’s no longer the issue of incompatible libraries. The transition is not yet complete, though.

Even though, the DateTime struct semantically defines a point-in-time in a concrete time zone, the Elixir standard library does not ship with the time zone database - this means that the functions in the DateTime module can only operate on structs in the Etc/UTC time zone requiring most libraries to include some third-party solution to deal with datetimes in other time zones.

The are many reasons not to ship with a time zone database, the two primary ones are the increase in size of the standard elixir release and the fact that the time zone database is often updated, which would tie the elixir release schedule to the time zone database update schedule.

The solution

Nonetheless, support for time zones is something we, the Elixir Core team, would like to include in the Elixir’s standard library. Unfortunately, we lack the required expertise and primarily the required time to properly design and implement this feature. That’s why we’ve decided to reach to you, the community, and ask for help. We’re asking you to propose possible solutions within the following design constraints and help us push Elixir forward.

Design constraints

Because we still don’t want to ship with time zone database in Elixir itself, we want the time zone library to be pluggable. To achieve this, the solutions needs two components - an interface for such a library defined in elixir itself (most probably a behaviour with one or more @callbacks) and a library implementing the behaviour and providing the time zone database to the standard library.

We don’t want the interface to be based on the current shape of the tzdata library. It has broad interfaces that often return collections of data you need to further process to retrieve the desired information. This means that for many operations a lot of data needs to be copied from the supporting ets tables making the library slower than it should be. The interface of the proposed library should be focused on speed and offer focused functions that give concrete answers to very specific queries.

When it comes to concrete implementations of the time zone database library there are many possibilities:

• compile the database into a module using macros;
• store in ets tables and update dynamically;
• call some C utility;
• and possibly more.

It’s important that we don’t want to focus on those yet. We want to look at what functions to define in standard library to take advantage of the time zone database and what interface we need from a time zone database provider. The time for concrete implementations will come later.

Proposal

The proposal should include 2 things:

• new functions in the Elixir standard library leveraging the time zone database
• a way to provide the time zone database to the Elixir standard library though a package.

The proposals should be RFC-style. This means they should be actionable and present concrete ideas and APIs, not just talk about principles and possibilities. A proposal should include signatures, typespecs and documentation drafts for all the new modules, functions and callbacks.

We intend Elixir 1.8 (estimated January 2019) to ship with those extensions. Thank you!