java.text.SimpleDateFormat.parse should recognize America/Los_Angeles

[Douglas Surber]

java.text.SimpleDateFormat.parse does not recognize time zone ids.

    new SimpleDateFormat("yyyy-MM-dd HH:mm:ss 
ZZZZ").parse("2015-03-03 09:25:00 America/Los_Angeles")

does not recognize "America/Los_Angeles" as a time zone. 
"America/Los_Angeles" is a time zone id and the "ZZZZ" format looks 
for time zone names such as "PST" and "Pacific Standard Time". None 
of the various time zone formats (or at least none that I have tried) 
will recognize a time zone id, eg America/Los_Angeles.

The code in question is in java.text.SimpleDateFormat.

   private int matchZoneString(String text, int start, String[] 
zoneNames) {
       for (int i = 1; i <= 4; ++i) {
           // Checking long and short zones [1 & 2],
           // and long and short daylight [3 & 4].
           String zoneName = zoneNames[i];
           if (text.regionMatches(true, start,
                                  zoneName, 0, zoneName.length())) {
               return i;
           }
       }
       return -1;
   }

The argument zoneNames is a 5 element array. Element 0 is a time zone 
id such as "America/Los_Angeles" and the next four are long and 
short, standard and daylight time names such as "PST" and "Pacific 
Daylight Time". This array comes from 
java.text.DateFormatSymbols.getZoneStringsWrapper, which returns an 
array of such String[]s.

Changing the initial index in the for loop from 1 to 0 would include 
the zone id in the set of Strings to compare and thus would match 
"America/Los_Angeles" or "Europe/London". It would also be necessary 
to modify SimpleDateFormat.subParseZoneString to correctly set 
useSameName. A simple change would be to test if nameIndex == 0 as 
the zone id is the same for standard and daylight time though this 
might not be correct as I haven't fully investigated how useSameName 
is used.

What exactly the various format character sequences are supposed to 
recognize is sufficiently vague that no change to the spec appears 
necessary, thought it might be beneficial.

A separate issue would be to consider the performance of doing 
regionMatches over this large String[][].

Douglas