Change in 2.11 for default ISO-8601 serialization of `java.util.Date`, `Calendar`: "+01:00" instead of "+0100"

18 views
Skip to first unread message

Tatu Saloranta

unread,
Jan 21, 2020, 10:43:23 PM1/21/20
to jacks...@googlegroups.com
So, quick question, related to 


in which request is made to improve ISO-8601 compatibility by serializing timezone offset including colon to separate hours and minutes (`X` for SimpleDateFormat String, over `Z`).

This setting has been accessible with `StdDateFormat.withColonInTimeZone()` already, but that is clumsy.

My concern, as usual, is with compatibility: while I agree in that such serialization is more compliant with ISO-8601 settings, no doubt some users somewhere are counting on existing serialization.
Ideally I also would not want to add yet another `SerializationFeature` here, although since it would be 2.x only (3.x can just default to new setting and have no override), that is not out of the question.

WDYT?

-+ Tatu +-



Michael

unread,
Jan 28, 2020, 5:11:26 PM1/28/20
to jacks...@googlegroups.com
So one thing that interests me is the idea of the 'basic' format vs. the 'extended' format, and how the colon separator fits in with that.

I'm not certain I have the 'right' documentation, as per what michael-o (other Mike) mentioned, but given the 'in extended format', would it be better to _add_ (supporting backwards compatibility) a way to specify extended format? As it stands, the only difference now would be the below setting, but this might protect against future issues where there are differences between extended and basic?


“:” (colon)the “:” colon character, in extended format, separates the time scale components for “hour” and “minute”, and “minute” and “second”.



--
You received this message because you are subscribed to the Google Groups "jackson-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jackson-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-dev/CAGrxA27DsMhWXjwS9Bs0mmPsc_PcF_hLr%3DprvE-jaGBvrsgQJA%40mail.gmail.com.


--
Written on a glass keyboard.

Michael

unread,
Jan 28, 2020, 5:36:48 PM1/28/20
to jacks...@googlegroups.com
Thinking about this a little more, making this the default in 3.0 seems fine.

Here's the reasoning:

Reading the definition of 'extended', my take is that extended is a superset of 'basic',so it stands to reason that having this as the default in 3.0 would be fine?

extended format:
extension of the basic format (3.1.3.4) that includes separators between its time scale components (3.1.3.3)

Tatu Saloranta

unread,
Jan 28, 2020, 6:16:38 PM1/28/20
to jacks...@googlegroups.com
On Tue, Jan 28, 2020 at 2:36 PM Michael <mich...@gmail.com> wrote:
Thinking about this a little more, making this the default in 3.0 seems fine.

Here's the reasoning:

Reading the definition of 'extended', my take is that extended is a superset of 'basic',so it stands to reason that having this as the default in 3.0 would be fine?

extended format:
extension of the basic format (3.1.3.4) that includes separators between its time scale components (3.1.3.3)

Default in 3.0 is to include colon at this point, so that's fine then I think.

But I guess now I am less confident about safety of change for 2.11.
If past is any guidance, changes to default settings of formatting tend to cause issue reports, including valid issues.

Does anyone know what would be default ISO-8601 formatting of java.util.Date/Calendar by other popular Java JSON libraries; in particular GSON? And maybe that one JSON-B implementation (johnzon?)

-+ Tatu +-

 
Reply all
Reply to author
Forward
0 new messages