Times in the BasicFileAttributes class

[Mark Thornton]

Alan Bateman wrote:
> Salter, Thomas A wrote:
>> I'm curious about the rationale behind representing file times 
>> (creationTime, lastAccessTime and lastModifyTime) as long integers 
>> with a separate resolution method.  
>> Since both Unix and Windows implementations currently return 
>> milliseconds, users might mistakenly create a java.util.Date object 
>> from the time without considering the units.  A bug like this 
>> wouldn't be detected until some new file system tried to used 
>> alternate units to express the times.
>>  
>> 1. Why limit the date range to dates since 1970?  This seems to be a 
>> Unix-centric view of the world. 2. Why not return a Date or Calendar 
>> object for these timestamps?
>> 3. Why does the Windows implementation discard the extra range and 
>> precision of Windows file times (100 ns units since 1600)?
>> 4. Is there a method somewhere that takes a long and a TimeUnit 
>> parameter and returns a Date or Calendat object?   It takes a fair 
>> amount of code to handle all the possible TimeUnit values.
>>  
>> Tom Salter
>>  
> While many developers will be used to working in milliseconds, file 
> systems and systems APIs have been moving to nanoseconds. We didn't 
> want to define an Instant class that would overlap with the work of 
> the date/time JSR. If that JSR goes into jdk7 then we can re-examine 
> this.
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.
>
> The issue with setting values to before 1970 came up on the nio-dev a 
> few weeks ago. It's an API bug and I hope to fix this soon. The 
> awkward issue is that we cannot specify required behavior for cases 
> where an application attempts to set the time to a value that 
> pre-dates the file systems's epoch. Ideally the method should specify 
> that the method fails or specifies that it sets the time to the file 
> system's epoch but these choices are just not feasible to implement in 
> all cases.
The FileTimeFactory suggested above can provide some information on the 
permitted range of values.

Regards,
Mark Thornton