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

[Stephen Colebourne]

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