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

[Xueming Shen]

Stephen,

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?

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.

Here is the "draft" of the FileTime change, comment and suggestion
appreciated.

http://cr.openjdk.java.net/~sherman/jdk8_threeten/filetime/

-Sherman