RFR: 8255078: sun/net/ftp/imp/FtpClient$MLSxParser uses wrong datetime format

[Daniel Fuchs]

On Tue, 20 Oct 2020 23:14:40 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this small patch?
> 
> according to [RFC3659](https://tools.ietf.org/html/rfc3659), time values in MLSx response have the following format: 
>>    time-val = 14DIGIT [ "." 1*DIGIT ] 
>> 
>>    The leading, mandatory, fourteen digits are to be interpreted as, in 
>>    order from the leftmost, four digits giving the year, with a range of 
>>    1000--9999, two digits giving the month of the year, with a range of 
>>    01--12, two digits giving the day of the month, with a range of 
>>    01--31, two digits giving the hour of the day, with a range of 
>>    00--23, two digits giving minutes past the hour, with a range of 
>>    00--59, and finally, two digits giving seconds past the minute, with 
>>    a range of 00--60 (with 60 being used only at a leap second). Years 
>>    in the tenth century, and earlier, cannot be expressed. This is not 
>>    considered a serious defect of the protocol. 
>> 
>>    The optional digits, which are preceded by a period, give decimal 
>>    fractions of a second. These may be given to whatever precision is 
>>    appropriate to the circumstance, however implementations MUST NOT add 
>>    precision to time-vals where that precision does not exist in the 
>>    underlying value being transmitted. 
>> 
>>    Symbolically, a time-val may be viewed as 
>> 
>>   YYYYMMDDHHMMSS.sss 
>> 
>>    The "." and subsequent digits ("sss") are optional. However the "." 
>>    MUST NOT appear unless at least one following digit also appears. 
>> 
> 
> `MLSxParser`, however, uses `SimpleDateFormat("yyyyMMddhhmmss")` (which is wrong b/c it uses `hh` instead of `HH` and doesn't account for optional `.sss`) to parse modify/create facts and ignore any parse exceptions.
> 
> `FtpClient` actually already has and uses `SimpleDateFormat` w/ right formats in `getLastModified` where it parses MDTM response, the patch refactors the code to reuse the same `SimpleDateFormat` in `MLSxParser`.
> 
> testing:
> * [x] tier1
> * [x] `test/jdk/sun/net` on `{linux,windows,macosx}-x64`

Hi Igor, is this testable - and if so shouldn't there be a test?
best regards,
-- daniel

-------------

PR: https://git.openjdk.java.net/jdk/pull/776