Conversation
9f05ac9 to
84dc47b
Compare
|
Rebased on top of current 3.0. |
|
Rebased again. Il would like to have the team's opinion about how to handle warnings in IntelliJ when a class uses APIs from Java 7+. The default behavior is to raise a compile warning, which is very useful. These errors can be suppressed with |
If I remove the FQDN from |
I'm on – err – 2016.1.3 (they completely changed their versioning scheme, so I'm a bit lost). By default, under "Preferences > Editor > Inspections > Java > Java language level migration aids", I had an inspection called "Usages of API which isn't available at the configured language level", set to Error severity. |
I see, I don't have that option, but I do have |
…eTimeCodec This commit contains contributions by Benoît Tellier (@chibenwa).
|
I've tried |
The present PR proposes to store zone IDs (such as
UTC,GMT, orEurope/Paris) instead of raw offsets (such as+00:00or-07:00), when this information is available.Zone IDs carry daylight savings time information, which offsets do not, and so can be more precise. One small drawback is that zone IDs are not ISO-8601 normalized, but I guess we can live with that.
I also strived to make both affected codecs,
ZonedDateTimeCodecandDateTimeCodec, compatible with each other, i.e., a tuple serialized by the former should be deserializable by the latter.And finally, I opened
ZonedDateTimeCodecto custom formatters, in case users would want to format or parse in a specific format. I did the same forDateTimeCodecbut only for the timestamp part, mainly because there is no proper parser/formatter for time zones: they have to be parsed by the built-in parser inDateTimeZone.forID(), which does not leave much room for customization.