I think this is premature. The docs for the time/tzdata package are clear that it should only be imported from a main package. I don't think we need to start planning for packages that go against those docs until we start seeing whether the problem actually occurs in practice.

@ianlancetaylor

it should only be imported from a main package

The language doesn't constraints this.

But only one question is why tzdata should be bundled optionally with an import? Transitive libraries can broke an environment for an app. Tags are still good.

New tag definitions add additional complexity and require additional documentation and testing. They also require additional work by users to understand what they mean. They are a fine tool when appropriate, but I see no reason to add them because of a purely speculative problem.

Also, how do you know when to use the tag? Unless you decide to use it all the time just in case, which seems unlikely for 99.9% of Go users, you'll identify the problem when you examine why your program is larger. And then you'll remove the unnecessary import, rather than using a tag.

Agree, probably it will be same to import _ "net/http/pprof" situation. This can be enforced via linter if needed.

Feel free to close this issue, thank you for fast response.

I still prefer tag-only version without another ability to change global state via imports, but probably it is not so user-friendly.

I agreed that is speculative problem.

Another examples: http.DefaultClient(which is bad pattern imho), rand.globalRand(seeds).
But there we can control them. If a library imports tzdata we can't control a binary size where it's needed.

The tzdata package has no API so the risk of people importing it for some symbol and accidentally getting the large side effect is less than other packages that mix side effects and API. That's probably a lesson to learn.

Sounds reasonable.

Consensus is that misuse risk is minimal, so closing.