Normalizing UTC time-zone to offset Z causes problems

[jodastephen]

Currently, we normalize time-zone IDs as follows:

 ZoneId.of("UTC")       -> ZoneOffset.UTC
 ZoneId.of("GMT")       -> ZoneOffset.UTC
 ZoneId.of("UT" )       -> ZoneOffset.UTC
 ZoneId.of("UTC+01:20") -> ZoneOffset.of("+01:20")
 ...

This can cause problems when swapping from TimeZone.

Best option I can think of is to not normalize on input, but provide a ZoneId.normalized() method to convert if needed.

See http://mail.openjdk.java.net/pipermail/threeten-dev/2013-February/000803.html

[jodastephen]

See patch https://gist.github.com/jodastephen/4757256

This retains the GMT/UTC/UT prefix in the ZoneId although it still normalizes the form of the offset part. UTC0 and UT0 are no longer valid IDs. The new normalized() method will be effective in conversion.

[jodastephen]

See http://hg.openjdk.java.net/threeten/threeten/jdk/rev/8abd40f9e8ef

The formatter parsing now needs to be changed to match this new behaviour.

[xuemingshen]

The ZoneIdPrinterParser now returns the ZoneOffset.UTC for UTC, GMT and UT for formatter of appendZoneId, appendZoneRegionId and appendZoneOrOffsetId. The implementation matches the spec. It might be desired to return a regional zoneid of "UTC", "GMT" and "UT" instead of ZoneOffset.UTC, if it's an appendzoneRegionId formatter. I think it's fine to leave the appendZoneId and appendZoneOrOffsetId asis. Is this something we want to do? Or just leave them asis?

[jodastephen]

What I want is that these two produce the same:
ZoneId.parse(str)
zoneIdFormatter.parse(str).query(ZoneId::from)

While there may be cases where that isn't practical, I suspect it is possible to do. I don't think there is any difference in parsing between appendZoneId(), appendZoneRegionId() and appendZoneOrOffsetId() today, and I'd expect that to stay the same.

IIRC, the main thing needing adding is IDs like "UTC" and "UTC+01:00".

[RogerRiggs]

Please confirm that to fix this ZoneIdPrinterParser.parse method should produce the same result as ZoneId.of().

[jodastephen]

Thats correct. This is about consistency.

Tthere is a separate question of whether there should be both ZoneId.of() and ZoneId.parse() where of is strict and parse is lenient.

[RogerRiggs]

jbs/bugs.sun.com bugid: 8016326

[RogerRiggs]

Resolved by http://hg.openjdk.java.net/threeten/threeten/jdk/rev/5a1d4618329c