Make not auto-updating the default about tzdata

[cdegroot]

It's a risk thing. Today we had a service crash at startup somewhere in the update. Code issue? Network issue? I don't know - there's extra complexity going on there that's not needed. I think that there's a tradeoff to be made: safe software (which starts with minimal surface area) versus the latest and greatest. Everyone needs safe software; not everybody has to be up to date with the absolulely latest TZ data - especially not if the library comes in as a transitive dependency (we got it through https://github.com/bitwalker/timex). It is prudent, especially if a library gains in popularity, to err on the safe side and disable any potentially unsafe behavior that's not strictly necessary, and then document how to enable that behavior. That's the proper choice to give users, not the other way around.

[lau]

The point of the library is to provide up-to-date data about time zones. The behaviour is the same. The code doesn't change - just the data. Think of it like a database system. The data can change and the systems using the database should be able to handle that the data in the database can change.

It is not random stuff from the internet, it is tzdata from Internet Assigned Numbers Authority (IANA). What is pulled in is the data which is the whole purpose of the library.

Did you have problems because the data updated?

[lau]

Today we had a service crash at startup somewhere in the update.

What specifically crashed? If it was the :tzdata_release_updater then it was probably restarted by its supervisor. Did anything stop working for you or were you just surprised about :tzdata_release_updater crashing?

Autoupdate is on by default because that is the best default for most people. People that haven't cared enough to read the README are likely to not bother updating to the newest tz database. If you handle non-UTC times and dates at all, you probably need an up-to-date version of the tz database.

[cdegroot]

It's your code, it's your right to decide either way.

[cdegroot]

(w.r.t. the actual crash - I've dug into our Splunk setup, here it is:

  crasher:
    initial call: Elixir.Tzdata.ReleaseUpdater:init/1
    pid: <0.1063.0>
    registered_name: tzdata_release_updater
    exception exit: {badarg,
                        [{erlang,hd,[[]],[]},
                         {'Elixir.Tzdata.DataLoader',
                             content_length_from_headers,1,
                             [{file,"lib/tzdata/data_loader.ex"},{line,29}]},
                         {'Elixir.Tzdata.DataLoader',do_latest_file_size,1,
                             [{file,"lib/tzdata/data_loader.ex"},{line,51}]},
                         {'Elixir.Tzdata.ReleaseUpdater',
                             'loaded_tzdata_matches_iana_file_size?',0,
                             [{file,"lib/tzdata/release_updater.ex"},
                              {line,48}]},
                         {'Elixir.Tzdata.ReleaseUpdater',poll_for_update,0,
                             [{file,"lib/tzdata/release_updater.ex"},
                              {line,36}]},
                         {'Elixir.Tzdata.ReleaseUpdater',handle_info,2,
                             [{file,"lib/tzdata/release_updater.ex"},
                              {line,17}]},
                         {gen_server,try_dispatch,4,
                             [{file,"gen_server.erl"},{line,601}]},
                         {gen_server,handle_msg,5,
                             [{file,"gen_server.erl"},{line,667}]}]}
      in function  gen_server:terminate/7 (gen_server.erl, line 812)
    ancestors: [<0.1057.0>,<0.1056.0>]
    messages: []
    links: [<0.1057.0>]
    dictionary: []
    trap_exit: false
    status: running
    heap_size: 1598
    stack_size: 27
    reductions: 8653
  neighbours:```

Stuff I do not want to see in production systems - crash reports should indicate actual problems, not a library doing something I'm really not interested in)