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

[Xueming Shen]

On 04/25/2013 11:22 AM, roger riggs wrote:
> Hi,
>
> The impetus was less with the appendValueReduced method itself
> but to be able to leverage the locale specific date patterns and be able
> allow a more flexible UI that would accept a more lenient years to be input.
>

Understood the requirement, just wonder maybe CLDR should be the one
to provide the correct data, maybe two sets of data, yy and yyyy or the
utility tool that pulls the data from the CLDR should tweak the data and
provide two styles of data with the default base value for the yy, instead
of "tweaking" the API to do the guess game. But when the data says yy it
should be 2 digits and when it is yyyy, it's 4 digits of year value. The 80/100
years plus minus might be big enough for birthday 20 years ago, but it might
be laughable 20 years later...my suggestion is to leave the guess game to
the application developer, if it's wrong, it only affects the individual
application, if JDK has a wrong guess, especially given our "compatibility,
compatibility and compatibility" slogan. But it's a "out of box" suggestion.

-Sherman


> In the CLDR data there are many forms that include 'yy' that could benifit
> the reduced input. There are very few forms that include yyyy.
>
> Roger
>
>
> On 4/25/2013 2:06 PM, Xueming Shen wrote:
>>
>>
>> Maybe an appendValueReducedAdjusted(..., ValueAdjuster) is something more
>> reasonable here? with
>>
>> interface ValueAdjuster {
>>     long adjust(TemporaField field, long value);
>> }
>>
>> While myself is really not a fan of this reduced_and_adjusted idea, I think we're
>> having enough interface and flexibility already here. But guess it at least has the
>> benefit of leaving appendValueReduced to what it is intended, without blurring the
>> spec and implementation with a "may/will be wrong in xyz years" base value.
>>
>> I always input 4 digits when asked during my web experience recently, I don't think
>> you can get away with a 2 digits year very often these days when you are being
>> asking mm/dd/yyyy...
>>
>> -Sherman
>>
>> On 04/25/2013 10:29 AM, Stephen Colebourne wrote:
>>>  In Joda-Time, the base value is set on the formatter, not the builder.
>>>  We could do the same, but I don't think its the right option (as we
>>>  allow anything to be truncated, not just one field. The same problem
>>>  applies to a bulider-wide base value. Thats why its necessary to tie
>>>  the base value in to the appendValueReduced().
>>>
>>>  We could have an appendPattern(String, Map<Field,Integer>) where the
>>>  map tells the method what base year to use. But realistically, no-one
>>>  woud use the method as they might as well use the builder proper at
>>>  that point.
>>>
>>>  I agree that 2000 may not satisfy the birthdate case, but only
>>>  something like (current - 100) would really satisfy that. Any other
>>>  choice is more arbitrary. It would have to be far enough in the future
>>>  that it won't become out of date (as it is in the spec it really
>>>  shouldn't be changed in the future). The 1940 to 1950 is just about
>>>  possible, but effectively makes this API expire in 2040/2050, which no
>>>  longer feel that far away.
>>>
>>>  A different value per JDK release is also likely to confuse, although
>>>  is at least more consistent than (current - 80).
>>>
>>>  I might be OK with a value that changes per JDK and once per decade.
>>>  So the value would be (jdk-release-year-rounded-down-to-decade - 80).
>>>  Which would be 1930 until a JDK relase in 202x. Although scheduling a
>>>  task to make that happen in 7 years time would be fun...
>>>
>>>  Stephen
>>>
>>>
>>>  On 25 April 2013 17:21, roger riggs<roger.riggs at oracle.com>   wrote:
>>>>  It depends on the use case,  for entering birthdates, SDF make more sense
>>>>  because it goes back 80 years.  Using valueReduced at  2000 goes back only
>>>>  13 years.
>>>>
>>>>  For the birthday case, a base of 1940 would be useful for ages up to 73.
>>>>  Any developer for this case will need to use DateTimeFormatterBuilder
>>>>  and hand craft the builder.
>>>>
>>>>  I would bias the range toward the past, not the future, I think 25 years in
>>>>  the
>>>>  future is plenty, though in 10 years, it would need to be reviewed.
>>>>
>>>>  Would it be reasonable to make the baseValue be a settable value
>>>>  in the Builder?  Then at least the developer could set the baseValue
>>>>  and then append the pattern to get the desired result.
>>>>
>>>>  Roger
>>>>
>>>>
>>>>
>>>>  On 4/25/2013 12:08 PM, Stephen Colebourne wrote:
>>>>
>>>>  On 25 Apr 2013 16:41, "roger riggs"<roger.riggs at oracle.com>   wrote:
>>>>>>  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.
>>>>  I think the SDF behaviour linking to current is poor design as any testing
>>>>  you do becomes null and void on Jan 1st. The 2000 base is pretty reasonable
>>>>  for today. Any other fixed JDK choice has real downsides.
>>>>
>>>>  Stephen
>>>>
>>>>
>>
>