[threeten-dev] Instant.MIN/MAX, LocalDate.MIN/MAX and Year.MIN/MAX_VALUE

[Stephen Colebourne]

On 4 April 2013 22:28, Xueming Shen <xueming.shen at oracle.com> wrote:
> While working on adding to/fromInstant to FileTime, the difference
> of the min/max value (year) of machine time and human time
> becomes a kinda of "block".  Have to copy/paste the "special
> handing" code from the InstantPP to handle the year specially
> (I'm pretty sure no real world code really care those years...).
> So just wonder what's the benefit of having the supported human
> time year off 1 from the machine time. The doc suggests that
> it tries to "provides sufficient values to handle the range of
> ZoneOffset, which affect the instant in addition to the LDT", but
> are we throwing away (invalidate) almost one year (between
> Instant and LDT/ZDT) to support/validate +/- 14 hrs of offsets?
> Or I'm reading the doc/code wrong?

There is non happy choice here that I could see.

I wanted LDT.at(offset) to work without error for every possible
date-time and offset. This means that the biggest ODT is
LDT.MAX.atOffset(ZoneOffset.MIN). We could set the Instant.MAX to that
value, but there would still be a gap of invalidity. The most
effective solution I could see was to make all the *DateTime classes
consistent and without error, but the Instant class be slightly
different (larger). The result is that min/max instants can't be
converted to LDT/ODT, but that has historically been the case in the
API (as Instant.MAX used to be Long.MAX_VALUE).


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


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

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

Stephen