lib/time: move zoneinfo.zip to src/time/tzdata

[FiloSottile]

I remember as a newcomer to be pretty confused by the top-level lib/ folder that didn't contain any library code. In the many years since, nothing but lib/time has been added to lib/.

As far as I understand, zoneinfo.zip exists so that if the GOROOT is available when the binary actually runs, time.LoadLocation will load it as the final fallback after checking system paths. (Relying on GOROOT at execution time is questionable, but not the point of this issue.)

When I mailed https://golang.org/cl/198062 there wasn't a clear place to move zoneinfo.zip, but after #38017 I think src/time/tzdata/ would be a natural place for it: if time/tzdata is imported, it gets embedded, and otherwise it will be searched under GOROOT as a fallback.

[gopherbot]

Change https://golang.org/cl/198062 mentions this issue: lib/time: move to src/time/tzdata

[dmitshur]

Also see #43350.

[ianlancetaylor]

I would not be surprised if moving these files breaks some people who trim their GOROOT. Of course, we may want to do it anyhow.

[FiloSottile]

Should Go 1.18 look in both $GOROOT/src/time/tzdata and $GOROOT/lib/time, or only the former? Do we want to support newer Go binaries running with an older GOROOT?

[ianlancetaylor]

My concern isn't that we should support an older GOROOT, it's that some people will install Go and then delete parts of GOROOT that they don't need. I don't know how likely this is.

[dmitshur]

Added early-in-cycle so this issue gets a reminder when the tree reopens. If we're going to do this, doing it earlier gives the greatest opportunity to find out what needs updating (outside of the Go project) and reverse course if we find out disruption is too significant. Based on information available in this issue so far, to me this change seems worth trying.

To reduce the risk of this contributing to a delay in the release schedule (CC @golang/release), it's possible to create and maintain (throughout the 1.18 cycle) a revert CL, to make it faster and safer to undo at any point before the final release, if case significant new findings come in very late in cycle.

CC @rsc as owner of package time, since this file is an internal component related to it.

[cagedmantis]

This issue is currently labeled as early-in-cycle for Go 1.18.
That time is now, so this is a friendly ping so the issue is looked at again.

[rsc]

Let's not make any changes here.

People have no doubt configured stripped-down execution environments that provide a $GOROOT containing only a lib/time directory, and there is no point in forcing them to update those scripts - which are working and probably long-forgotten - by changing the location of the timezone database.

Historically, on Unix systems, lib directories often contained general reference files besides compiled libraries - look in /usr/lib on a Linux system, and note that two of the other hard-coded locations are /usr/share/lib/zoneinfo/ and /usr/lib/locale/TZ/. It turned out that nothing else ended up in GOROOT/lib, but that's OK.

If we were starting over, then sure, src/time/tzdata might be a reasonable location. But so is the current location, and the churn and breakage required to change it is not worth the (almost zero) benefit.

As Brad said on the CL, adding a lib/README.md would be fine.