This repository has been archived by the owner. It is now read-only.

Normalizing UTC time-zone to offset Z causes problems #262

Closed
jodastephen opened this Issue Feb 8, 2013 · 8 comments

Comments

Projects
None yet
3 participants
@jodastephen
Member

jodastephen commented Feb 8, 2013

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

This comment has been minimized.

Show comment
Hide comment
@jodastephen

jodastephen Feb 11, 2013

Member

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.

Member

jodastephen commented Feb 11, 2013

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

This comment has been minimized.

Show comment
Hide comment
@jodastephen

jodastephen Feb 19, 2013

Member

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

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

Member

jodastephen commented Feb 19, 2013

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

This comment has been minimized.

Show comment
Hide comment
@xuemingshen

xuemingshen May 2, 2013

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?

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

This comment has been minimized.

Show comment
Hide comment
@jodastephen

jodastephen May 3, 2013

Member

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".

Member

jodastephen commented May 3, 2013

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

This comment has been minimized.

Show comment
Hide comment
@RogerRiggs

RogerRiggs Jun 7, 2013

Contributor

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

Contributor

RogerRiggs commented Jun 7, 2013

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

@jodastephen

This comment has been minimized.

Show comment
Hide comment
@jodastephen

jodastephen Jun 7, 2013

Member

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.

Member

jodastephen commented Jun 7, 2013

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.

@ghost ghost assigned RogerRiggs Jun 11, 2013

@RogerRiggs

This comment has been minimized.

Show comment
Hide comment
@RogerRiggs

RogerRiggs Jun 11, 2013

Contributor

jbs/bugs.sun.com bugid: 8016326

Contributor

RogerRiggs commented Jun 11, 2013

jbs/bugs.sun.com bugid: 8016326

@RogerRiggs

This comment has been minimized.

Show comment
Hide comment

@RogerRiggs RogerRiggs closed this Jun 11, 2013

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.