Times in the BasicFileAttributes class

[Salter, Thomas A]

I'd like to encourage you to change the resolution for Windows so that it is not the same as Unix.  I suspect most applications get tested on both Windows and some of flavor of Unix/Linux, so if those implementations are different applications will be forced to honor the TimeUnit resolution.



-----Original Message-----
From: Alan.Bateman at Sun.COM [mailto:Alan.Bateman at Sun.COM]
Sent: Friday, April 03, 2009 11:30 AM
To: Salter, Thomas A
Cc: nio-discuss at openjdk.java.net
Subject: Re: Times in the BasicFileAttributes class

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.