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.
That produces the same output using both of the formats...
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...
...yields this output:
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...
-i