Tzdata 2.0 plans about tzdata

[cdegroot]

It is important that these warnings are visible by default so that users won't miss it

I can honestly state that I've never seen the warning. Logs go to Splunk/Sumo/Cloudwatch and one time that I did notice it was when I specifically dug into an outgoing firewall warning ("why is this production system trying to talk with IP a.b.c.d"?).

Did y'all consider just forcing the user to make a choice? Crash when Application.get_env(:tzdata, :check_for_updates) is nil? Given that this is a discussion where I can defend either default, this might just be a situation where "no default" is the best outcome.

[lau]

I can honestly state that I've never seen the warning

They haven't been created yet. This is a plan for a future version.

Logs go to Splunk/Sumo/Cloudwatch and one time that I did notice it was when I specifically dug into an outgoing firewall warning ("why is this production system trying to talk with IP a.b.c.d"?).

That sounds like an anecdote about the current version. The answer to your question is in one of the first lines of the README. The README also covers instructions for how to configure this.

[cdegroot]

The answer to your question is in one of the first lines of the README

I think we've been here before - the library is an important indirect dependency in the Elixir ecosystem for most users, and only few users will end up stumbling upon the README.

And yes, that's "hey, what's going on here?" is about the current version. I'm happy that attempts are made to address that and just trying to add something to the thinking by suggesting forcing the user to make an explicit decision here - whether a transient dependency reaches out to IANA or hex.pm, it's the call-home-by-default decision that's troublesome (at least it will, based on this proposal, not update a deployed package which is a big step forward, thanks for considering that). But I guess that that station has been long passed.

[epinault]

is this still in the work? Hackney is depending on a very old lib and also seems it would be best to rely on a more default client within erlang