Time zone support for Elixir.
The Elixir standard library does not ship with a time zone database. As a result, the functions in the DateTime
module can, by default, only operate on datetimes in the UTC time zone. Alternatively (and
deliberately), the standard library relies on
third-party libraries, such as tz
, to bring in time zone support and deal with datetimes in other time zones than UTC.
The tz
library relies on the time zone database maintained by
IANA. As of version 0.12.0, tz
uses version tzdata2020f of the IANA time zone database.
The tz
library is tested against nearly 10 million past dates, which includes most of all possible imaginable
edge cases.
Time zone periods are deducted from the IANA time zone data. A period is a period of time where a certain offset is observed. Example: in Belgium, from 31 March 2019 until 27 October 2019, clock went forward by 1 hour; this means that during this period, Belgium observed a total offset of 2 hours from UTC time.
The time zone periods are computed and made available in Elixir maps during compilation time, to be consumed by the DateTime module.
tz
can watch for IANA time zone database updates and automatically recompile the time zone periods.
To enable automatic updates, add Tz.UpdatePeriodically
as a child in your supervisor:
{Tz.UpdatePeriodically, []}
If you do not wish to update automatically, but still wish to be alerted for new upcoming IANA updates, add
Tz.WatchPeriodically
as a child in your supervisor:
{Tz.WatchPeriodically, []}
This will simply log to your server when a new time zone database is available.
Lastly, add the http client mint
and ssl certificate store castore
into your mix.exs
file:
defp deps do
[
{:castore, "~> 0.1.5"},
{:mint, "~> 1.0"},
{:tz, "~> 0.12.0"}
]
end
To use the tz
database, either configure it via configuration:
config :elixir, :time_zone_database, Tz.TimeZoneDatabase
or by calling Calendar.put_time_zone_database/1
:
Calendar.put_time_zone_database(Tz.TimeZoneDatabase)
or by passing the module name Tz.TimeZoneDatabase
directly to the functions that need a time zone database:
DateTime.now("America/Sao_Paulo", Tz.TimeZoneDatabase)
Refer to the DateTime API for more details about handling datetimes with time zones.
tz
provides two environment options to tweak performance.
You can decrease compilation time, by rejecting time zone periods before a given year:
config :tz, reject_time_zone_periods_before_year: 2010
By default, no periods are rejected.
For time zones that have ongoing DST changes, period lookups for dates far in the future will result in periods being dynamically computed based on the IANA data. For example, what is the period for 20 March 2040 for New York (let's assume that the last rules for New York still mention an ongoing DST change as you read this)? We can't compile periods indefinitely in the future; by default, such periods are computed until 5 years from compilation time. Dynamic period computations is a slow operation.
You can decrease period lookup time for such periods lookups, by specifying until what year those periods have to be computed:
config :tz, build_time_zone_periods_with_ongoing_dst_changes_until_year: 20 + NaiveDateTime.utc_now().year
Note that increasing the year will also slightly increase compilation time, as it will generate more periods to compile.
Add tz
for Elixir as a dependency in your mix.exs
file:
def deps do
[
{:tz, "~> 0.12.0"}
]
end
HexDocs documentation can be found at https://hexdocs.pm/tz.