Find bad DateTimeZone.forID / TimeZone.getTimeZone parameters

[cpovirk]

@kluever found ~20 files with occurrences of "America/Los Angeles" (rather than "America/Los_Angeles"). I see ~15 with "America/New York."

There are at least two ways to approach this:

• In about 1/3 of these cases is the string literal used directly as a parameter to one of the standard "create a time zone" methods. For those cases, we can actually call the method at compile time (or otherwise maintain a list of known good time zones) -- if we trust for the data available to Error Prone to match the data available at runtime. The upside here is that we catch not only space-underscore mixups but also misspellings.
• Regardless of how it is being used, "America/Los Angeles" is unlikely to be correct. We could error out on all strings with apparent space-underscore time-zone mixups (or on all strings with an edit distance close to a known time zone -- edit-distance support may show up in Guava in 2016, if that helps).

(Does JDK8 have any new time-zone APIs? Maybe ZoneId.of?)

[cpovirk]

Kurt points out that some of these APIs will, when given a bad timezone, actually return The Unknown Timezone rather than throw an exception as I would have expected.

[eaftan]

It looks like org.joda.time.DateTimeZone, java.util.TimeZone, and java.time.ZoneId all have getAvailableIDs methods that enumerate all valid ID strings, so we could just check against those.

We have edit distance already in Error Prone: https://github.com/google/error-prone/blob/master/core/src/main/java/com/google/errorprone/util/EditDistance.java

[cpovirk]

InvalidTimeZoneID was introduced to cover TimeZone.getTimeZone, but I'm not sure we did anything with the other two.

[cpovirk]

Oh, wait, there's InvalidZoneId, too. So maybe just not the Joda one, which we care less about.