[threeten-dev] Instant.MIN/MAX, LocalDate.MIN/MAX and Year.MIN/MAX_VALUE
Xueming Shen
xueming.shen at oracle.com
Fri Apr 5 11:39:54 PDT 2013
On 04/05/2013 03:55 AM, Stephen Colebourne wrote:
>
>
>> It appears FileTime have to have its own "format/toStrong" instant
>> of leveraging the JSR310 formatting mainly because
>>
>> 1) it follows the existing jdk/"old" ISO 8601 formatting behavior for BCE
>> years, in which dis-allows the 0000 for proleptic year 0.
>>
>> 2) LocalTime formats the "ss" part optionally. It appears to takes the
>> "it is acceptable to omit lower order time elements..." alternative.
>>
>> 3) FileTime formats the "fraction of second" part as "decimal fraction"
>> while LT uses SSS, SSSSSS or SSSSSSSSS pattern. So the FT strips
>> any tailing zero, but LD does not if it fits into the 3-letter unit.
>> Stephen, any reason behind this design decision, or it is specified
>> by the standard.
> LocalTime has to pretend that it is multiple classes (to avoid class
> combination explosion). So, it pretends to be an HourMin class, by
> printing a suitable toString, it also pretends to be an HourMinSec
> class. For decimal fractions it is also more consistent with
> SimpleDateFormat to show all three digits for millis.
>
> Using DateTimeFormatterBuilder, you can easily produce a formatter
> that can format/parse the FileTime format however.
>
> builder
> .appendText(ERA, mapOfZeroToMinusSignAndOneToEmptyString)
> .appendValue(YEAR_OF_ERA, 4)
> ...
> .appendFraction(NANO_OF_SECOND, 0, 9)
>
You can always use pattern, I'm a little concerned about the performance.
But since it's immtable, so the formatter can be shared. Will try later
after some measurement.
>> Here is the "draft" of the FileTime change, comment and suggestion
>> appreciated.
>>
>> http://cr.openjdk.java.net/~sherman/jdk8_threeten/filetime/
> to(TimeUnit unit)
> unit.convert(instant.getEpochSecond(), TimeUnit.SECONDS) +
> unit.convert(instant.getNano(), TimeUnit.NANOSECONDS);
> will not saturate correctly to MIN/MAX
>
> toMillis()
> instant.toEpochMilli(); will throw ArithmeticException, so you'll have
> to catch and convert to MIN/MAX.
>
> hashCode()
> Because toInstant() can't repesent all values of FileTime, the
> hashCode's uniqueness is compromised.
>
> Same truncation problem in toString()
> Also, you have a one line if statement which is misisng its braces.
>
>
> An alternate approach would be to convert on input to the existing the
> long+TimeUnit storage mechanism. Conversion would be immediate, and
> could spot trailing zeroes in the Instant and choose a larger
> TimeUnit. Truncation would be possible, but unlikely.
>
You will have the same "truncation" problem, though being consistent with
the hash/equal...I don't think the truncation will cause real problem in real
application, but might need better wording in spec to clarify.
> Really, I would prefer to see the class changed to be a
> TemporalAccessor. That way, it could return INSTANT_SECONDS and be
> passed directly to the formatter (which handles values greater than
> Instant.MAX). This would require a simple enhancement to the instant
> formatter to control fractional seconds (which is needed and I'm
> raising an issue for).
It can be address later, we can always to implement TemporalAccessor,
if desired/requested later. Who will really need a FileTime beyond
Instant.MIN/MAX? :-)
-Sherman
> Stephen
More information about the threeten-dev
mailing list