Times in the BasicFileAttributes class

[Salter, Thomas A]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-discuss/attachments/20090403/e8b2cc86/attachment.html