I noticed that java.time.format.DateTimeFormatter
is not able to parse out as expected. See below:
import java.time.LocalDate;
import java.time.format.DateTimeFormatter;
public class Play {
public static void tryParse(String d,String f) {
try {
LocalDate.parse(d, DateTimeFormatter.ofPattern(f));
System.out.println("Pass");
} catch (Exception x) {System.out.println("Fail");}
}
public static void main(String[] args) {
tryParse("26-may-2015","dd-L-yyyy");
tryParse("26-May-2015","dd-L-yyyy");
tryParse("26-may-2015","dd-LLL-yyyy");
tryParse("26-May-2015","dd-LLL-yyyy");
tryParse("26-may-2015","dd-M-yyyy");
tryParse("26-May-2015","dd-M-yyyy");
tryParse("26-may-2015","dd-MMM-yyyy");
tryParse("26-May-2015","dd-MMM-yyyy");
}
}
Only the last attempt with tryParse("26-May-2015","dd-MMM-yyyy");
will "Pass". As per the documentation LLL
should be able to parse out textual format. Also note the subtle difference of the uppercase 'M' vs lowercase 'm'.
This is really annoying, as I cannot by default parse out strings formatted by default by Oracle DB
SELECT TO_DATE(SYSDATE,'DD-MON-YYYY') AS dt FROM DUAL;
Similarly, for following program:
import java.time.LocalDate;
import java.time.format.DateTimeFormatter;
public class Play {
public static void output(String f) {
LocalDate d = LocalDate.now();
Locale l = Locale.US;
// Locale l = Locale.forLanguageTag("ru");
System.out.println(d.format(DateTimeFormatter.ofPattern(f,l)));
}
public static void main(String[] args) {
output("dd-L-yyyy");
output("dd-LLL-yyyy");
output("dd-M-yyyy");
output("dd-MMM-yyyy");
}
}
I get below output:
28-5-2015
28-5-2015
28-5-2015
28-May-2015
Clearly the L
Format specifier doesn't treat anything textual, seems numeric to me ...
However, if I change the Locale to Locale.forLanguageTag("ru")
, I get the following output:
28-5-2015
28-Май-2015
28-5-2015
28-мая-2015
All really interesting, wouldn't you agree?
The questions I have are:
L
pattern specifier.Quoting a part from the documentation that I percieved as 'it matters':
Text: The text style is determined based on the number of pattern letters used. Less than 4 pattern letters will use the short form. Exactly 4 pattern letters will use the full form. Exactly 5 pattern letters will use the narrow form. Pattern letters 'L', 'c', and 'q' specify the stand-alone form of the text styles.
Number: If the count of letters is one, then the value is output using the minimum number of digits and without padding. Otherwise, the count of digits is used as the width of the output field, with the value zero-padded as necessary. The following pattern letters have constraints on the count of letters. Only one letter of 'c' and 'F' can be specified. Up to two letters of 'd', 'H', 'h', 'K', 'k', 'm', and 's' can be specified. Up to three letters of 'D' can be specified.
Number/Text: If the count of pattern letters is 3 or greater, use the Text rules above. Otherwise use the Number rules above.
UPDATE
I have made two submissions to Oracle:
I believe 'L' is meant for languages that use a different word for the month itself versus the way it is used in a date. For example:
Locale russian = Locale.forLanguageTag("ru");
asList("MMMM", "LLLL").forEach(ptrn ->
System.out.println(ptrn + ": " + ofPattern(ptrn, russian).format(Month.MARCH))
);
Output:
MMMM: марта
LLLL: Март
There shouldn't be any reason to use 'L' instead of 'M' when parsing a date.
I tried the following to see which locales support stand-alone month name formatting:
Arrays.stream(Locale.getAvailableLocales())
.collect(partitioningBy(
loc -> "3".equals(Month.MARCH.getDisplayName(FULL_STANDALONE, loc)),
mapping(Locale::getDisplayLanguage, toCollection(TreeSet::new))
)).entrySet().forEach(System.out::println);
The following languages get a locale-specific stand-alone month name from 'LLLL':
Catalan, Chinese, Croatian, Czech, Finnish, Greek, Hungarian, Italian, Lithuanian, Norwegian, Polish, Romanian, Russian, Slovak, Turkish, Ukrainian
All other languages get "3" as a stand-alone name for March.