Return to Answer

I would recommend you to add in a test to check for every available Locale on the platform, if you can parse a date formatted using that locale.

The corresponding test would be:

@Test
public void testAllLocales() {
 LocalDate specificLocalDate = LocalDate.of(2014, 10, 2);
 
 Locale[] locales = Locale.getAvailableLocales();
 for (Locale locale : locales) {
 DateTimeFormatter dateTimeFormatter = DateTimeFormatter.ofLocalizedDate(FormatStyle.SHORT).withLocale(locale);
 String date = specificLocalDate.format(dateTimeFormatter);
 
 LocalDate localDate = DateParser.parseShortDate(date, locale);
 
 assertEquals("for " + date + " using " + locale, specificLocalDate, localDate);
 }
}

Using this we find a few sneaky bugs:

1. It does not work for the locale hr_HR, as it uses date format dd.MM.yy, which has a dot at the end. To fix this we need to change the DATE_PATTERN_EXTRACTION_PATTERN to Pattern.compile("^\\W*(\\w+)\\W+(\\w+)\\W+(\\w+)\\W*$"). Note that we now allow any number matches of non-words at the start and end of the date format.
2. The DATE_PATTERN_EXTRACTION_PATTERN should work using Unicode, as languages may possibly use Unicode characters as separators, so it should be: Pattern.compile("(?iuU)^\\W*(\\w+)\\W+(\\w+)\\W+(\\w+)\\W*$").
3. There is bug using the locale zh_HK, supposedly due to unicode characters in the formatted date, as it is not able to extract the three numbers from the date.
4. The ja_JP_JP_#u-ca-japanese locale does not work, but this may be due to a JDK bug: http://stackoverflow.com/questions/26169008/the-ja-jp-jp-u-ca-japanese-locale-cannot-be-reparsed-by-its-own-pattern-using-t

I would recommend you to add in a test to check for every available Locale on the platform, if you can parse a date formatted using that locale.

The corresponding test would be:

@Test
public void testAllLocales() {
 LocalDate specificLocalDate = LocalDate.of(2014, 10, 2);
 
 Locale[] locales = Locale.getAvailableLocales();
 for (Locale locale : locales) {
 DateTimeFormatter dateTimeFormatter = DateTimeFormatter.ofLocalizedDate(FormatStyle.SHORT).withLocale(locale);
 String date = specificLocalDate.format(dateTimeFormatter);
 
 LocalDate localDate = DateParser.parseShortDate(date, locale);
 
 assertEquals("for " + date + " using " + locale, specificLocalDate, localDate);
 }
}

Using this we find a few sneaky bugs:

1. It does not work for the locale hr_HR, as it uses date format dd.MM.yy, which has a dot at the end. To fix this we need to change the DATE_PATTERN_EXTRACTION_PATTERN to Pattern.compile("^\\W*(\\w+)\\W+(\\w+)\\W+(\\w+)\\W*$"). Note that we now allow any number matches of non-words at the start and end of the date format.
2. The DATE_PATTERN_EXTRACTION_PATTERN should work using Unicode, as languages may possibly use Unicode characters as separators, so it should be: Pattern.compile("(?iuU)^\\W*(\\w+)\\W+(\\w+)\\W+(\\w+)\\W*$").
3. There is bug using the locale zh_HK, supposedly due to unicode characters in the formatted date, as it is not able to extract the three numbers from the date.
4. The ja_JP_JP_#u-ca-japanese locale does not work, but this may be due to a JDK bug: https://stackoverflow.com/questions/26169008/the-ja-jp-jp-u-ca-japanese-locale-cannot-be-reparsed-by-its-own-pattern-using-t

I would recommend you to add in a test to check for every available Locale on the platform, if you can parse a date formatted using that locale.

The corresponding test would be:

@Test
public void testAllLocales() {
 LocalDate specificLocalDate = LocalDate.of(2014, 10, 2);
 
 Locale[] locales = Locale.getAvailableLocales();
 for (Locale locale : locales) {
 DateTimeFormatter dateTimeFormatter = DateTimeFormatter.ofLocalizedDate(FormatStyle.SHORT).withLocale(locale);
 String date = specificLocalDate.format(dateTimeFormatter);
 
 LocalDate localDate = DateParser.parseShortDate(date, locale);
 
 assertEquals("for " + date + " using " + locale, specificLocalDate, localDate);
 }
}

Using this we find a few sneaky bugs:

1. It does not work for the locale hr_HR, as it uses date format dd.MM.yy, which has a dot at the end. To fix this we need to change the DATE_PATTERN_EXTRACTION_PATTERN to Pattern.compile("^\\W*(\\w+)\\W+(\\w+)\\W+(\\w+)\\W*$"). Note that we now allow any number matches of non-words at the start and end of the date format.
2. More issues arise on more exotic locales, but I'm not sure if it is worth the time to deal with them, as the primary use case seems to be a Latin font.

I would recommend you to add in a test to check for every available Locale on the platform, if you can parse a date formatted using that locale.

The corresponding test would be:

@Test
public void testAllLocales() {
 LocalDate specificLocalDate = LocalDate.of(2014, 10, 2);
 
 Locale[] locales = Locale.getAvailableLocales();
 for (Locale locale : locales) {
 DateTimeFormatter dateTimeFormatter = DateTimeFormatter.ofLocalizedDate(FormatStyle.SHORT).withLocale(locale);
 String date = specificLocalDate.format(dateTimeFormatter);
 
 LocalDate localDate = DateParser.parseShortDate(date, locale);
 
 assertEquals("for " + date + " using " + locale, specificLocalDate, localDate);
 }
}

Using this we find a few sneaky bugs:

1. It does not work for the locale hr_HR, as it uses date format dd.MM.yy, which has a dot at the end. To fix this we need to change the DATE_PATTERN_EXTRACTION_PATTERN to Pattern.compile("^\\W*(\\w+)\\W+(\\w+)\\W+(\\w+)\\W*$"). Note that we now allow any number matches of non-words at the start and end of the date format.
2. The DATE_PATTERN_EXTRACTION_PATTERN should work using Unicode, as languages may possibly use Unicode characters as separators, so it should be: Pattern.compile("(?iuU)^\\W*(\\w+)\\W+(\\w+)\\W+(\\w+)\\W*$").
3. There is bug using the locale zh_HK, supposedly due to unicode characters in the formatted date, as it is not able to extract the three numbers from the date.
4. The ja_JP_JP_#u-ca-japanese locale does not work, but this may be due to a JDK bug: http://stackoverflow.com/questions/26169008/the-ja-jp-jp-u-ca-japanese-locale-cannot-be-reparsed-by-its-own-pattern-using-t