On May 22, 2017, at 3:52 PM, Stuart Marks <stuart.ma...@oracle.com> wrote:
>> --- 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.
True.
> 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.
Or it could say “its mathematically absolute value” which would be accurate.
> 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.
Yes, I read about HFS Plus as part of investigating another time issue.
>> 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.
Good!
Thanks,
Brian
