Align ISO timezone parsing in DateFormatter with Joda-Time / JSR-310 [SPR-14675]

[spring-projects-issues]

Per Holmberg opened SPR-14675 and commented

First, the javadoc example for DateTimeFormat.ISO.DATE_TIME is wrong; literal 'T' should be used between date and time. But even when this corrected it does not work:

DateFormatter formatter = new DateFormatter();
formatter.setIso(DateTimeFormat.ISO.DATE_TIME);
formatter.parse("2000-10-31T01:30:00.000-05:00", Locale.getDefault());

Reason is the pattern specified in DateFormatter is wrong; for ISO, X should be used for timezone instead of Z (se javadoc for SimpleDateFormat). Correct pattern: yyyy-MM-dd'T'HH:mm:ss.SSSXXX

I guess same applies to DateTimeFormat.ISO.TIME.

---

Affects: 4.2.7, 4.3.2

Issue Links:

• @DateTimeFormat(iso = ISO.DATE_TIME) should use optimized formatter for LocalDateTime [SPR-14958] #19525 @DateTimeFormat(iso = ISO.DATE_TIME) should use optimized formatter for LocalDateTime

Referenced from: commits bb94ba6, db196ce, a5070d5, 68332bf, d5c9cc6

[spring-projects-issues]

Juergen Hoeller commented

I see your point, and DateFormatter's parsing indeed differs from our Joda-Time and JSR-310 equivalents, with Joda-Time leniently accepting both "-05:00" and "-0500" but JSR-310 only accepting "-05:00" and DateFormatter only "-0500". While we certainly recommend the use of Joda-Time / JSR-310 date-time types, we should revisit the somewhat simplistic DateFormatter as well. I'm afraid we can only do that in 5.0 though since the existing format may be relied on in applications out there, not just for parsing but also for rendering... and subtle breakages might only get noticed at runtime.

So for the time being, specifying a custom pattern is the only way out if you can't use Joda-Time or JSR-310. I'll revise the javadoc with respect to the 'T' separator and will add a note on implementation-specific parsing differences.

[spring-projects-issues]

Juergen Hoeller commented

As of 5.0 M4, DateFormatter's ISO patterns use {XXX}} as discussed above, aligned with JSR-310 processing which it is typically auto-configured with.

Note that DefaultFormattingConversionService still prefers Joda-Time for Date and Calendar processing, if present at runtime.