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

[roger riggs]

Hi,

On 4/25/2013 6:07 AM, Stephen Colebourne wrote:
> 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.
ok, the min/max form provided a way on formatting to be able to get the
complementary behavior on formatting of formatting the full year if the 
two digit
form was not in range of the base.
>
> 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.
yes, the patterns will cause the least confusion if they match.
On a related note, should we consider using the heuristic for the base 
year  (current - 80)?
Currently it is a bit awkward Year.now().getYear();  developers might
take the shortcut and stick in some value they think is useful but it 
will vary
from app to app and get stale.
>
> 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
Seems reasonable.
>
> 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".
ok, for lenient, the width does not need to be constrained

Thanks, Roger

>
> 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