Times in the BasicFileAttributes class

[Alan Bateman]

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.

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.

It's purely an implementation choice that the Windows implementation 
currently returns the timestamps in milliseconds. It is easily changed 
to use nanoseconds but we don't have a solution for code that ignores 
the resolution. As regards conversion - all I can suggest is to use 
TimeUnit.MILLISECONDS.convert(lastModifiedTime(), resolution()) if you 
require the value in ms.

-Alan.