If the number of pattern letters is 1, any fraction of an hour is ignored. For example, if the pattern is "X" and the time zone is "GMT+05:30", "+05" is produced.
Ha! So the 'X' pattern has built-in precision and I needed to handle that correctly. Specifying a single 'X' would always ignore the minutes component of the time zone and I'd get an incorrect time. All I had to do was specify 'XX' to get the times to parse correctly.
Lets see some examples...
First lets see what a time zone that doesn't have a significant minutes component behaves like. In this case I am using the GMT+11 time zone.
Time zone without minutes component
// Default time zone is UTC
TimeZone.setDefault(TimeZone.getTimeZone("UTC"));
String dtString = "20160209193500+1100";
System.out.println((new SimpleDateFormat("yyyyMMddHHmmssXX"))
.parse(dtString).toString());
System.out.println((new SimpleDateFormat("yyyyMMddHHmmssX"))
.parse(dtString).toString());
That produces the same output using both of the formats...
Output
Tue Feb 09 08:35:00 UTC 2016
Tue Feb 09 08:35:00 UTC 2016
Now lets see when the time zone is changed to +1030 i.e. 10 hours 30 minutes offset from GMT. Changing the time string to this...
Time zone with a 30 minute component
...
String dtString = "20160209193500+1030";
...
...yields this output:
Output
Tue Feb 09 09:05:00 UTC 2016
Tue Feb 09 09:35:00 UTC 2016
The Date object is now 30 minutes out if the lower precision time zone format is used.
Interestingly if the old 'Z' format is used i.e. 'yyyyMMddHHmmssZ', the time is parsed with the same precision in both cases.
So one would ask why should this new format be used when it has this precision issue/feature? Well the answer is that the ISO 8601 time zones are more versatile.
For example if you try to parse a 2-digit time zone (e.g. '20160209193500+11') using the old RFC 822 format, you will get this exception...
Exception
Exception in thread "main" java.text.ParseException: Unparseable date: "20160209193500+11"
at java.text.DateFormat.parse(DateFormat.java:357)
-i
