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) > <https://www.iso.org/obp/ui#iso:std:iso:8601:-1:ed-1:v1:en:term:3.1.3.4> > that includes separators between its time scale components (3.1.3.3) > <https://www.iso.org/obp/ui#iso:std:iso:8601:-1:ed-1:v1:en:term:3.1.3.3> > On Tue, Jan 28, 2020 at 4:11 PM Michael <[email protected]> wrote: > 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”. > > > https://www.iso.org/obp/ui#iso:std:iso:8601:-1:ed-1:v1:en > > > On Tue, Jan 21, 2020 at 9:43 PM Tatu Saloranta <[email protected]> > wrote: > >> So, quick question, related to >> >> https://github.com/FasterXML/jackson-databind/issues/1624 >> >> 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 +- >> >> >> >> -- >> 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jackson-dev/CAGrxA27DsMhWXjwS9Bs0mmPsc_PcF_hLr%3DprvE-jaGBvrsgQJA%40mail.gmail.com >> <https://groups.google.com/d/msgid/jackson-dev/CAGrxA27DsMhWXjwS9Bs0mmPsc_PcF_hLr%3DprvE-jaGBvrsgQJA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > > > -- > Written on a glass keyboard. > -- Written on a glass keyboard. -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-dev/CAEBemP1uCy_FRMqmnnkhD-9rHS3mY63FZMj_yDTYP5cpf-7T8g%40mail.gmail.com.
