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
