Hi 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(); http://cr.openjdk.java.net/~sherman/8011647/webrev 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 performance. (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. http://cr.openjdk.java.net/~sherman/8011647/TestFileTime.java http://cr.openjdk.java.net/~sherman/8011647/TestFileTimeBM.java 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. Thanks, -Sherman
