@ -47,7 +47,25 @@ The following sections provide guidance on lenient parsing for `@DateTimeFormat`
As mentioned previously in this document, the Spring team recommends the use of ISO standardized formats or concrete patterns for both parsing and formatting of date/time values whenever possible. For time values, this can be achieved via `@DateTimeFormat(iso = ISO.TIME)` (which uses the `HH:mm:ss.SSSXXX` pattern) or `@DateTimeFormat(pattern = "h:mm a")` (which uses the `h:mm a` pattern that is compatible with `java.text.DateFormat.SHORT` and Spring's `-S` style for parsing and formatting time values, prior to the changes introduced in CLDR 42).
As mentioned previously in this document, the Spring team recommends the use of ISO standardized formats or concrete patterns for both parsing and formatting of date/time values whenever possible. For time values, this can be achieved via `@DateTimeFormat(iso = ISO.TIME)` (which uses the `HH:mm:ss.SSSXXX` pattern) or `@DateTimeFormat(pattern = "h:mm a")` (which uses the `h:mm a` pattern that is compatible with `java.text.DateFormat.SHORT` and Spring's `-S` style for parsing and formatting time values, prior to the changes introduced in CLDR 42).
> **TODO** Document benefits of `fallbackPatterns` in `@DateTimeFormat`.
To make your application more robust to changes in the CLDR or simply to support multiple parsing patterns simultaneously, you can configure custom `fallbackPatterns` in `@DateTimeFormat`. Please note, however, that fallback patterns are only used for parsing. They are not used for printing the value as a string. The _primary_`pattern`, `iso`, or `style` attribute is always used for printing.
For example, if you wish to use the ISO time format for printing and as the primary parsing pattern but allow for lenient parsing of user input for alternative time formats, you could configure something similar to the following.
Similary, if you wish to always print times using the locale-sensitive pattern in the current version of the CLDR (which may vary depending on the Java runtime environemnt) but allow for lenient parsing of user input for alternative time formats, you could configure something similar to the following.