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

[roger riggs]

Hi Sherman,

True, common use case is for fields that are years. But there are 
several year fields:
YEAR, YEAR_OF_ERA, and the localized WEEK_BASED_YEARs
so the field argument can't be removed.  I don't think the method will 
be used
extensively but would prefer to keep it flexible.

Roger

On 4/25/2013 7:03 PM, Xueming Shen wrote:
>
> 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
>>
>