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

[Xueming Shen]

Do we expect this new appendValueReduced(field, minwidth, maxwidth, basevaluse)
method provide benefit for any other temporal field? or it most likely will only be used
for the special yy/uu->yyyy parsing? My limited knowledge/experience does not bring
in any other usage for other field (other calendar system?). If this is the case, maybe it
should simply be more specific as appendYearValueReduced(baseValue)? with the specific
description of supporting 2 digits year and 4 digits year formatting/parsing?

-Sherman


On 04/25/2013 03:06 PM, roger riggs wrote:
> Hi,
>
> Updated as recommended below:
>
> Webrev:
>     http://cr.openjdk.java.net/~rriggs/webrev-lenient-parse-218/
>
> One open question is whether lenient parsing of numbers (including
> ValueReduced) should respect the maxWidth.
> Currently, NumberPrinterParser uses maxWidth to limit the width of the parse.
> The ReducedPrinterParser needs an upper bound on the width to parse
> leniently.
>
> Another minor issue is the range of text width and range of BaseValue.
> The original code allowed field widths of up to 19 but the baseValue
> was limited to an int and the table of powers of ten was limited to 10 digits.
> Is there a recommended range for fields that might use ReducedValue parsing?
>
> Thanks, Roger
>
>
> 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.
>>
>> 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
>