DateTimeFormatter does not parse months as described in JavaDocs

[michael-o]

According the JavaDocs numbers are parsed this way: "Number: The minimum number of digits. Shorter numbers are zero-padded to this amount."

Consider this code:
DateTimeFormatter fmt = DateTimeFormat.forPattern("yyyy-MM");
DateTime dt = fmt.parseDateTime("2013-9");

It does not throw an expection, it silently ignores the fact that a padding zero is necessary. Java's SimpleDateFormat at least documents this inconsistency. Anyway, I would expect parsing to work the very same way as formatting a DateTime.

[jodastephen]

Joda-Time has tended to have more lenient parsing than formatting, this is one example. Its not going to change now (backward compatibility and upcoming JSR-310) but it could be better documented.

[michael-o]

OK but documentation must be improved. Can you add a boolean flag for strict parsing?

[michael-o]

From JSR 310 JavaDoc:

"Number: If the count of letters is one, then the value is printed using the minimum number of digits and without padding as per DateTimeFormatterBuilder.appendValue(java.time.temporal.TemporalField). Otherwise, the count of digits is used as the width of the output field as per DateTimeFormatterBuilder.appendValue(java.time.temporal.TemporalField, int)."

I fail to find the notion that this is non-strict parsing. SimpleDateFormat explicitly mentions this.

[jodastephen]

JSR-310 has explicit strict/lenient/smart modes.

Joda-Time has an explicit appendFixedDecimal method on the builder class that can be used to obtain strict parsing.

[michael-o]

Stephen, the method you provided me does not seem to be very intuitive. I have already provided in the pattern 'yyyy-MM' how may digits I want, why do I need to repeat it? Cannot this be done automatically, if I configure a boolean strict on a formatter?

[jodastephen]

You use DateTimeFormatterBuilder instead of using a pattern. The patterns are there for the common cases, if you have more specific cases not covered then the API provides the builder.

[michael-o]

I have evaluated the builder and this works:

DateTimeFormatterBuilder builder = new DateTimeFormatterBuilder();
builder.appendFixedDecimal(DateTimeFieldType.year(), 4);
builder.appendLiteral('-');
builder.appendFixedDecimal(DateTimeFieldType.monthOfYear(), 2);
builder.appendLiteral('-');
builder.appendFixedDecimal(DateTimeFieldType.dayOfMonth(), 2);
DateTimeFormatter parser = builder.toFormatter();

LocalDate date = parser.parseLocalDate("2013-9-13");
System.out.println(date);

This fails as desired. This has two implications:

1. It is impossible to parse strict with a given string pattern
2. The ISODateTimeFormat is broken because this 2013-9-14 is not a valid ISO date string but

DateTimeFormatter isoParser = ISODateTimeFormat.date();

LocalDate date = isoParser.parseLocalDate("2013-9-14");
System.out.println(date);

Accepts this input. Shall I raise another issue?

[jodastephen]

If you want to raise another issue, you can, however I can't change ISODateTimeFormat due to backward compatibility. The best I could do would be more documentation. And yes, it is far from ideal as is.

Adding a dateStrict() method would be possible if it weren't for the fact that there are lots and lots of methods in that class.

A better issue would be the addition of a strict mode, however that would be a big change at this point in Joda-Time's life and not one I'm planning on making.

[michael-o]

This is a pity. I simply do not understand why this issue has not been discovered before.

A strict mode would be perfect. At least, what about a ISODateTimeStrictFormat with a improved along its way?

[jodastephen]

If you want to create a pull request with a StrictISODateTimeFormat class I'd probably accept that. It wouldn't have to have all of the formats from the current class, just a selection of useful ones. It would need some tests to be accepted ;-)

[michael-o]

Stephen, that's fine. I would create a pull request in time. Are you able to improve the documentation of the ISODateTimeFormat class? It should crearly say that it does not comply with ISO 8601.