Take the following example:
@Test
public void testJoda()
{
DateTimeFormatter formatter = new DateTimeFormatterBuilder()
.appendYear(4, 6)
.appendMonthOfYear(2)
.toFormatter();
assertEquals(new LocalDate(2004, 1, 1), formatter.parseDateTime("200401").toLocalDate());
assertEquals(new LocalDate(10004, 1, 1), formatter.parseDateTime("1000401").toLocalDate());
assertEquals(new LocalDate(10004, 1, 1), formatter.parseDateTime("10000401").toLocalDate());
}
This fails because the DateTimeFormatter will eagerly assume that all 6 digits are the year, and then move on to parse the month, only to find no data available. I think that if this occurs, the parser should backtrack to try lengths 5 and 4.
I will admit that the year 10,000 is completely ridiculous for most applications, but unfortunately I have seen data which included one, and it happened to be using no delimiter, which resulted in my discovery of this issue when I tried to adjust its parser to accept 5 digits.
Yes, its a problem. ThreeTen/JSR-310 gets it right, but its not simple code.