Times in the BasicFileAttributes class

[Alan Bateman]

Mark Thornton wrote:
> A rather belated response to this, but something I have been thinking 
> about for some time. I think there would be some merit in using a very 
> simple form of Instant that was based internally on the unconverted 
> data from the OS. Thus on Windows it would hold a long value in 100ns 
> units based on 1601.
>
> abstract class FileTime implements Comparable<FileTime>, 
> javax.time.InstantProvider {
>    public abstract long getRawValue();
>    public abstract long toMillis();
>    public abstract javax.time.Instant toInstant();
>    // Implement toString to return the ISO8601 format time with all 
> available resolution
> }
>
> The InstantProvider interface  and toInstant() method is from JSR310, 
> while toMillis provides compatibility with the existing date/time 
> classes (and alternatives like Joda).
> In addition provide a FileTimeFactory:
>
> abstract class FileTimeFactory {
>    public static FileTimeFactory system();
>    public abstract long rawResolution();
>    public abstract long rawEpochMillis();
>    public abstract FileTime getMinimumValue();
>    public abstract FileTime getMaximumValue();
>    public abstract FileTime millisInstant(long millis);
>    public abstract FileTime instant(javax.time.Instant t);
>    public abstract FileTime raw(long rawValue);
> }
>
> Such a scheme would be safer than just returning long values and is 
> easy to make compatible with JSR-310 should it be available.
Just to follow up on this (and other discussion with Mark Thornton on 
this topic),  I've pushed a simple FileTime to the repository:
  
http://openjdk.java.net/projects/nio/javadoc/java/nio/file/attribute/FileTime.html
It's not a million miles from Mark's proposal  except that it doesn't 
use a per-provider factory and doesn't expose the raw value. We can 
easily retrofit it to implement InstantProvider in the future without 
needing updates to all providers. In the default provider they will be 
created with second, microsecond or maybe nanosecond precision. The 
Windows implementation rounds 100ns values to microseconds. If folks 
really care about the additional precision then this is easily changed 
to use nanoseconds for values where it is feasible.

The API bug that prevented setting timestamps to times before 1970 is 
also fixed. As per other mails, attempts to set timestamps to times that 
pre-date the file system/volume epoch results in undefined behavior. A 
couple of cases have special handling, like on Windows attempts to set a 
file on FAT32 to a time before 1980 will fail so it retries with 
1/1/1980. Similarly on Solaris when attempting to set files on NFS or 
ZFS to times before 1970. Further work could be done on this but it 
depends on the operating system reporting an error (which isn't true 
everywhere).

-Alan.