The classes javafx.util.converter.[Date|Time|DateTime]StringConverter use the default format styles (SHORT, MEDIUM, LONG) based on the locale, which causes unwanted formats in many cases.
Since these classes are intended for controls like ComboBox, etc, the style for the default formatters should have been set explicitly to SHORT.
For example, in the en_US locale, a date value will show as "Jan 12, 1985" where "01/12/1985" is probably a more desirable format for an interactive control. I don't expect that end users want to type three letter month names, for example.
A solution can be to add constructors to allow setting the date and time styles, but the bigger question is whether the default styles should be changed so they are set to SHORT automatically. That would break behavior from FX 8, but the alternative would be to add javadoc recommending that the developer should specify SHORT instead of using the default constructor.
Note also thatRT-38011 will add an API set to create converters based on the new java.time.Local[Date|Time|DateTime] APIs, and these converters will have SHORT applied explicitly from the beginning.
It is possible that we should close this bug as "will not fix", and add emphasized recommendations in the converter classes to use theRT-38011 API, i.e. to use the new java.time classes instead of java.util.Date and Calendar.
Since these classes are intended for controls like ComboBox, etc, the style for the default formatters should have been set explicitly to SHORT.
For example, in the en_US locale, a date value will show as "Jan 12, 1985" where "01/12/1985" is probably a more desirable format for an interactive control. I don't expect that end users want to type three letter month names, for example.
A solution can be to add constructors to allow setting the date and time styles, but the bigger question is whether the default styles should be changed so they are set to SHORT automatically. That would break behavior from FX 8, but the alternative would be to add javadoc recommending that the developer should specify SHORT instead of using the default constructor.
Note also that
It is possible that we should close this bug as "will not fix", and add emphasized recommendations in the converter classes to use the
- relates to
-
JDK-8098254 StringConverter support for LocalDate/LocalTime/LocalDateTime
- Resolved
-
JDK-8094008 Missing @since tags for some 8u40 API
- Resolved
-
JDK-8088604 [DateTimeStringConverter] missing javadoc for protected fields
- Closed
-
JDK-8097697 Review API for 8u40
- Resolved