JDK 9 doc-api-only RFR of 6791812: (file spec) Incompatible File.lastModified() and setLastModified() for negative time

[Roger Riggs]

Hi Brian,

I don't think you need to mention the absolute value.

+     *          file does not exist or if an I/O error occurs; the value may
+     *          be negative indicating the number of milliseconds before the epoch

Roger



On 5/22/2017 6:55 PM, Brian Burkhalter wrote:
> On May 22, 2017, at 3:52 PM, Stuart Marks <stuart.marks at 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