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).
Thanks for taking time to think about this as it's been hanging around 
for some time (I'm guilty for putting it on the long finger as I didn't 
know if JSR-310 was coming or not). An interim solution for a simple 
Instant-like object seems reasonable (and we later retrofit it to 
implement InstantProvider if JSR-310 is added) . I'm happy to work with 
you on a proposal. One initial comment is that we are deliberately 
using, and adjusting to, the java epoch to avoid adding complexity. Also 
having FileTime encapsulate the value and resolution is closer to what I 
have been thinking (so 100ns units would be adjusted to ns to allow it 
be qualified by a TimeUnit).

> 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 FileTimeFactory suggested above can provide some information on 
> the permitted range of values.
Just on that, I don't think it is feasible for a implementation to know 
the range. For the default file system at least, the valid range is the 
intersection of what the operating system supports via its APIs and the 
range supported by the underlying file system/volume. There are many 
cases where the latter isn't available/known, particularly with remote 
file systems. There are cases where we can adjust but many other cases 
where we cannot.

-Alan.