The set of supported time zones on a system are always system dependent. They depend entirely on what files are installed on the system.

Closing because I don't see how we can fix it. Please comment if you disagree.

I'm sorry, I didn't explain the bug clearly enough. This bug is related to Go incorrectly parsing the local zoneinfo. Zoneinfo has strict case sensitivity. time.Location.name is set based on the input to LoadLocation. This value is validated by reading the zone file from the case insensitive HFS+ filesystem, and never case-corrected to the on-filesystem case. As a result, any variation of casing will result in LoadLocation succeeding, despite the returned name being an invalid zone.

This happens in line 206 in https://golang.org/src/time/zoneinfo_read.go.

Here is the identical Java program running on the same machine, parsing the same zoneinfo:

import java.util.TimeZone;

public class Location {
  public static void main(String[] args) {
    String[] locInput = {
      "America/New_York",
      "America/new_york"
    };
    for (String input : locInput) {
      TimeZone loc = TimeZone.getTimeZone(input);
      System.out.println("input: " + input + ", output: " + loc.getID());
    }
  }
}

Output:

input: America/New_York, output: America/New_York
input: America/new_york, output: GMT

(TimeZone.getTimeZone returns GMT on error)

See that Java's interpretation of the local zoneinfo is case-sensitive and fails to parse "America/new_york".

Zoneinfo has strict case sensitivity

Paul Eggert, the current editor and maintainer of the tzdata database, has a "Theory and pragmatics of the tz code and data" doc here: https://github.com/eggert/tz/blob/master/Theory.

Regarding case-sensitivity, the doc says:

Here are the general rules used for choosing location names,
in decreasing order of importance:

[...]

[rule 3]
Do not use names that differ only in case. Although the reference
implementation is case-sensitive, some other implementations
are not, and they would mishandle names differing only in case.

The document acknowledges the existence of implementations that are not case-sensitive, so we're not the only outlaws out there.

On the other hand, I quote, "the reference implementation is case-sensitive", so one could argue that it'd be nice to make the Go implementation case-sensitive.

Re-opening, and labelling NeedsDecision.

If we decide to change something, what would we change?

I'd say: if the user asks for America/new_york but on the machine filesystem there's an America/New_York file, we return "not found", even if we are on a case-insensitive file system, where the open(America/new_york) call still works (because the file system ignores case). This would make the time package case-sensitive on macOS. It's already case-sensitive everywhere else (where the file system is case-sensitive).

I'm assuming the macOS filesystem allows you to retrieve the "actual" file name (with the upper case letters). Is this possible?

LoadLocation(name) opens "/usr/share/zoneinfo/"+name. If "america/new_york" exists, then it exists. I don't see how to avoid that. There is no such thing as an official name, and in particular nothing inside the file says "America/New_York". So this is not a bug related to parsing the file data. This data is not in the file.

Time is a very low-level package. It's not at all clear that we should add complexity to try to divine the "official" OS file name just to check for people passing lower case names.

I think we're going to leave this alone.

I think it's fine to not fix this, but it should be more clearly documented that Go is deviating from the expected convention when you call location.String(), and is unsuitable for use as the canonical name for the zone.

This was surprising to me, and had I seen the documentation earlier I would have implemented an alternative package that gave me access to the actual names, and not the user-input which may or may not be the name.

@mconbere Are you suggesting that we add a sentence to the docs for time.(*Location).String along the lines of "Note that this may not be the canonical name of the timezone."?

Go is not deviating from the expected convention: the caller is. time.Location.String just returns the name passed to time.LoadLocation. If the caller passes in a non-standard name to time.LoadLocation, it hardly seems reasonable to fault Go for passing it back.