Reconsider fallback date formats for ISO variants in DateTimeFormatterRegistrar

[membersound]

spring-boot-starter-webflux-2.6.4

The following controller can take a date in yyyy-MM-dd format in a @PostMapping request without problems, but fails for a @GetMapping query parameter.

@RestController
public class DateTimeServlet {    
    static class DateTimeDto {
        private LocalDate date;
        //getter, setter
    }

    @PostMapping("/datetime")
    public Mono<String> datetimePost(@RequestBody DateTimeDto dto) {
        return Mono.just("OK");
    }

    @GetMapping("/datetime")
    public Mono<String> datetimeGet(DateTimeDto dto) {
        return Mono.just("OK);
    }
}

Works:

POST localhost:8080/datetime
{
    "date": "2022-02-02"
}

Does not work:

GET localhost:8080/datetime?date=2022-02-02

Result:

{
    "timestamp": "2022-03-03T08:57:56.248+00:00",
    "status": 400,
    "message": "'date': : Parse attempt failed for value [2022-02-02]. rejectedValue: 2022-02-02"
}

Why are get and post requests behaving that differently? Shouldn't either both succeed, or both fail?

Update: while I discovered that POST bodies are converted using jackson, and GET parameters using Spring Conversation Service, I wonder if it wouldn't be better that both could have the same behavior?

[wilkinsona]

The difference in behaviour is because the POST that uses @RequestBody is being converted by Jackson, whereas the GET is being converted using a ConversionService. Jackson uses DateTimeFormatter.ISO_LOCAL_DATE by default for the conversion whereas the ConversionService uses DateTimeFormatter.ofLocalizedDate(FormatStyle.SHORT).

We could consider changing these defaults for Spring Boot 3.0 so that they align. Beyond that, this issue is really a duplicate of spring-projects/spring-boot#30041.

[membersound]

Okay, so the workaround for the moment is:

spring.webflux.format.date=ISO
spring.webflux.format.time=ISO
spring.webflux.format.date-time=ISO

[bclozel]

Looking at this issue transferred from Spring Boot, we could reconsider in the 6.0 timeline the date time fallback formats to use ISO variants instead of FormatStyle.SHORT.

[sbrannen]

• Closing as a duplicate of DateTimeFormatterRegistrar should fall back to ISO parsing by default #26985.