What possible advantages do you see using persistent_term over compiling into maps and recompilation?
Yes. At runtime it does not access the file system (only during compilation). And thank you for sharing that limitation of escript, let’s always take that into account when new ideas come up.
Well, simplified persistent term does exactly this. Recompile a module. But using pattern matching on function heads, rather than using a function that select from a map.
So as I’m not aware how your current implementation looks like, changing to persistent term might increase lookup performance while still being easily updatable at runtime.
There is one disadvantage though - it need to be done on each startup, while precompiled module can be, well, precompiled 
The point is that you can do both in BEAM - have precompiled module and then recompile it when needed. So it was more out of interest rather that being useful in the implementation. However recompiling the module with the tz which would use patter matching instead of map lookup should be the nicest solution out there.
can you develop that idea? 
currently the lookup is done by traversing the list of time zone periods (a period is a map with :from and :to entries) and checking if the timestamp (the given date for which we want to find the period) is included in the period; it’s linear, starting by the most recent period. I can optimize this by adding guards to the generated functions that return the period maps, in order to divide the periods; instead of
def periods("Europe/Brussels")
have
def periods("Europe/Brussels", timestamp) when timestamp > A and timestamp < B
def periods("Europe/Brussels", timestamp) when timestamp > C and timestamp < D
# and so on
Note that I think this is an optimization only for the lookup of very old dates; I wonder sometimes, who really needs that.
That will increase the function clauses though. Then I can also generate different function names per time zone and/or have a module per continent. There are a lot of parameters and possible optimizations.
However not sure what you meant by pattern matching instead of map lookup.
Here are some major updates for tz:
1. Reduced lookup time
Testing nearly 10 million past dates on my machine took around ~430 seconds. I could reduce it to ~260 seconds. In the previous version, periods were looked up linearly as they were simply stored in a list. In the current version, this list of periods has been divided into a map, grouped by year. The data grew larger but I could keep the compilation time relatively low, by compiling the periods into modules per area as @josevalim suggested (one module for “Europe/”-time zones, “Asia/”-time zones, etc.).
(Note that I tried to work with function clauses instead, but either compilation was too slow, or after decreasing clauses, lookup was slower, or it led to errors due to too many quoted blocks, …; changing the data structure seemed most efficient in terms of lookup/compilation time balance).
2. Performance tweaks
Two environment options may be given to tz to tweak performance.
→ Decrease period lookup time for dates in the future:
config :tz, build_periods_with_ongoing_dst_changes_until_year: 20 + NaiveDateTime.utc_now().year
Looking up periods for far-future dates for a time zone that has DST changes is expensive, as tz has to dynamically compute those periods. It is now possible to specify until what year periods have to be pre-compiled. This does not affect period lookup time for past periods 
, as periods are now stored into a map grouped by year; in the previous version, this option would drastically increase lookup time for past dates, as the search was linear (i.e. the more data you added, the slower it was).
→ Decrease compilation time by rejecting old periods that are never going to be looked up:
config :tz, reject_time_zone_periods_before_year: 2010
These options have been documented in the readme file with their defaults.
You want automatic updates. I listened.
tz comes now with optional automatic updates.
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 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 if any update is found.
mint, a pure Elixir HTTP client, and castore need be added in the dependency list.
This addition to the library does not slow down compilation time nor lookup time.
How does it work? (Also, need your feedback)
When a new available IANA tz database is found, the modules are recompiled with the new time zone data.
I might need some review for this piece of code:
case :erlang.get(:elixir_compiler_pid) do
:undefined -> &Task.async/1
_ -> &Kernel.ParallelCompiler.async/1
end
I use :erlang.get(:elixir_compiler_pid) to know whether we are in compile-time or run-time. If compile-time, modules (per time zone area) are compiled in parallel using the function Kernel.ParallelCompiler.async/1. If run-time, modules are compiled in parallel using the function Task.async/1.
Modules are purged after recompilation:
Module.create(module, contents, Macro.Env.location(__ENV__))
:code.purge(module)
Does this seem alright? Updates work fine for me this way.
Thank you for your feedback!
This seems generally sound, although I on the HTTP front I think your best bet is to create a Tz.HTTPClient behaviour and make the dependency on :mint and :castore optional. This way people can plug in their own HTTP client if they’re already using one in particular. I can’t comment on the recompilation strategy sorry.
In addition to tz, I provide a small tool tz_extra which allows to obtain, for each time zone, the most recent offsets, the countries observing the time zone, and other useful information. It also allow you to list all the countries (iso 3166 file provided by iana).
The purpose is to build time zone pickers and country pickers; for example my attempt in building a time zone picker:
The data can also be automatically updated (utc/dst offset may change, country names may change, …).
More information in the GitHub repo’s README:
https://github.com/mathieuprog/tz_extra
