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

[Xueming Shen]

-------- Original Message --------
Message-ID: 	<51796E5B.8020704 at oracle.com>
Date: 	Thu, 25 Apr 2013 10:56:43 -0700
From: 	Xueming Shen <xueming.shen at oracle.com>
User-Agent: 	Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 	1.0
To: 	Stephen Colebourne <scolebourne at joda.org>
Subject: 	Re: [threeten-dev] Review for parsing 2 to 4 years #218
References: 	<517855F2.3000403 at oracle.com> <CACzrW9BR-gvGx_D5Vy1C=LOMJfr+JgkuXxbvVHFY=AJW-8m-Ng at mail.gmail.com> <51794073.2050800 at oracle.com> <CACzrW9BEeKd9oyP7P4jzsteNrpK8S3uATc1JgeLJAA2+VF8b+A at mail.gmail.com> <517957EE.8040400 at oracle.com> <CACzrW9B_PjVDNXazBTi0BPArKB7PBgO4K_9g+b+k4QCZpCFYew at mail.gmail.com>
In-Reply-To: 	<CACzrW9B_PjVDNXazBTi0BPArKB7PBgO4K_9g+b+k4QCZpCFYew at mail.gmail.com>
Content-Type: 	text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 	7bit



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