Codereview Request: 8011647: Add java.time.Instant methods to java.nio.file.attribute.FileTime
xueming.shen at oracle.com
Thu Apr 11 20:47:01 UTC 2013
As part of the JSR310 Date/Time project, following methods are proposed
to be added into java.nio.file.attribute.FileTime to interoperate with the
new JSR310 time class Instant.
public static FileTime from(Instant instant);
public Instant toInstant();
Here are some notes regarding the changes.
(1) With its <long, TimeUnit> design, the FileTime can store the time point
on the time-line further in the future and further in the past than the Instant.
To be consistent with the spec and implementation of existing to(TimeUnit)/
toMillis(), the proposed toInstant() saturates to the Instant.MIN/MAX when
converting from a FileTime object that is beyond the supported time range
of Instant (instead of throwing a "conversion failure" exception, such as a
DateTimeException). Time points beyond the Instant range are not interesting
in practical cases.
(2) The internal supporting class DaysAndNanos is replaced by using the threeten
Instant class directly. As the direct consequence, the hashCode() for those time
points beyond the Instant.MIN/MAX range will be "compromised/saturated" into
the hashCode value of Instant.MIN/MAX. As mentioned in (1), since those time
points are not the interest of the FileTime class in real world use scenario, so we
believe this is an acceptable compromise. The hashCode/equal contract still
holds, though the usages of those "extra time points" may trigger worse
(3) compareTo() still provides correct ordering for all supported "time points",
including those beyond Instant.MIN/MAX range.
(4) toString() has been rewritten to use the threeten LocalDateTime class
together with the "home-made" formatting code for better performance.
Differences of the spec/implementation of FileTime and JSR310 date/time
class listed below prevents us from using the new JSR310 formatter to format
the FileTime directly.
a) FileTime uses "old" ISO8601 version, in which it dis-allows the '0000' for
proleptic year 0, while the JSR310 formats "0000" (which is supported in new
version of 8601), so the format for all BCE years are different.
b) LocalTime formats the "ss" part optionally. It appears to takes the "it is
acceptable to omit lower order time elements..." alternative, while the "ss"
part is mandated in FileTime toString(), even the second part is 0.
c) FileTime formats the "fraction of second" part as "decimal fraction" while
LocalTime uses SSS, SSSSSS or SSSSSSSSS pattern. So the FT strips any tailing
zero, but LocalDate does not if it fits into the 3-dit unit.
Two addition tests have been used to provide more confidence for the
"compatibility" and performance.
It is also suggested that it might be convenient for FileTime to implement
java.time.TemporalAccessor, so the FileTime can be directly formatted
by the JSR310 formatter. This is not included in this proposal. I may consider
to add this in a later round of update.
More information about the core-libs-dev