On 5/19/17 11:59 AM, Brian Burkhalter wrote:
https://bugs.openjdk.java.net/browse/JDK-6791812--- a/src/java.base/share/classes/java/io/File.java +++ b/src/java.base/share/classes/java/io/File.java @@ -932,7 +932,9 @@ * @return A <code>long</code> value representing the time the file was * last modified, measured in milliseconds since the epoch * (00:00:00 GMT, January 1, 1970), or <code>0L</code> if the - * file does not exist or if an I/O error occurs + * file does not exist or if an I/O error occurs; the value may + * be negative in which case its absolute value indicates the + * number of milliseconds before the epoch * * @throws SecurityException * If a security manager exists and its {@link
This is "absolutely" pedantic, but the absolute value of Long.MIN_VALUE is Long.MIN_VALUE, which is still negative. A negative value for "milliseconds before the epoch" is confusing. It might be sufficient simply to say that negative values indicate a time prior to the epoch.
This is not outside the realm of possibility. For example, the Mac HFS+ file system represents time as seconds since January 1, 1904. It seems unlikely :-) that any Mac files were actually created between 1904 and 1970, but it is a possibility that somebody could have set a file's timestamp to a date in that range.
The weird thing here is that if this method were invoked on a file last modified at 00:00:00 GMT, January 1, 1970, then we would not know whether the file does not exist or whether its last-modified time is the epoch. It seems to me that if the file does not exist it would be better to throw a FileNotFoundException but that is not an issue for JDK 9 at this stage of game.
I'll comment on this on the subsequent thread. s'marks
