| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8181362 | 10 | Brian Burkhalter | P3 | Resolved | Fixed | b10 |
| JDK-8180778 | 9.0.4 | Brian Burkhalter | P3 | Resolved | Fixed | b01 |
java.io.File says
A long value representing the time the file was last modified, measured in milliseconds since the epoch (00:00:00 GMT, January 1, 1970),
But just because the *units* are milliseconds, doesn't mean that the returned value is necessarily accurate down to the millisecond.
The File API should clarify the distinction and give the expected accuracy for common platforms.
A long value representing the time the file was last modified, measured in milliseconds since the epoch (00:00:00 GMT, January 1, 1970),
But just because the *units* are milliseconds, doesn't mean that the returned value is necessarily accurate down to the millisecond.
The File API should clarify the distinction and give the expected accuracy for common platforms.
- backported by
-
JDK-8180778 File.lastModified should specify accuracy as well as resolution
-
- Resolved
-
-
-
- Resolved
-
- relates to
-
JDK-8180767 A return value of zero from java.io.File#lastModified() is ambiguous
-
- Closed
-
-
-
- Closed
-
-
JDK-6791812 (file spec) Incompatible File.lastModified() and setLastModified() for negative time
-
- Closed
-
- links to
(1 links to)