@ -49,22 +49,28 @@ As mentioned previously in this document, the Spring team recommends the use of
@@ -49,22 +49,28 @@ As mentioned previously in this document, the Spring team recommends the use of
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.
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 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.
If you wish to achieve something similar for date/time formats, you could configure `@DateTimeFormat` as follows.
If you wish to achieve something similar for date/time formats, you could configure `@DateTimeFormat` as follows.
If you wish to use a US English locale based time format – with a standard space before `AM` or `PM` – for printing and as the primary parsing pattern but allow for lenient parsing of input that contains a narrow non-breaking space before `AM` or `PM`, you could configure something similar to the following.
Although not generally recommended, if you need to 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.