[threeten-dev] Review for parsing 2 to 4 years #218

[Stephen Colebourne]

My concern is that this change caters too much for the edge case and
not enough for the typical use case. In the typical use case, the user
just wants to format/parse a fixed 2 digit year. The change to the
builder now means they have to specify two widths, not one. We should
retain the method with one width argument at the very least.

Next, it seems that the behaviour is different to SimpleDateFormat,
where parsing anything other than the specified width results in a
pure year, not a year merged with the base year. At the very least, we
need a way to replicate that, so our patterns match SDF.

This would seem sensible behaviour:
* appendValueReduced(YEAR, 2, 2000)
* format = lowest 2 digits of year, zero padded if necessary
* parse-strict = only accept two digits and apply base year
* parse-lenient alone (yy/MM) = parse as though it were
appendValue(YEAR). If 2 digits parsed then apply base year.
* parse-lenient not adjacent (yyMMdd) = parse as though it were
appendValue(YEAR) with 4 reserved digits for MMdd. If 2 digits parsed
then apply base year.
* parse-lenient adjacent (MMddyy) = same as parse-strict

Beyond that, the new method you're proposing seems to be controlling
the maximum width of parsing allowed in lenient mode. I guess that is
fine, but I'm not sure it would see wide applicability. We generally
just say lenient is lenient, and I don't think a maxWidth concept
should apply at all in strict mode in the context of "reduced".

Sorry this change seems more complex than I expected.
Stephen



On 24 April 2013 23:00, roger riggs <roger.riggs at oracle.com> wrote:
> Hi,
>
> Cleanup of the changes for addValueReduced and the ReducedPrinterParser.
> The parseStrict and parseLenient logic re-introduced so that by default
> the behavior of appendPattern("yyMMdd") will result in a fixed width parse
> unless setLenient is called in the DateTimeFormatterBuilder.
>
> Webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-lenient-parse-218/
>
> Please review.
>
> Thanks, Roger
>
> [1] https://github.com/ThreeTen/threeten/issues/218