[This defect may affect other parsers too -- I haven't checked.]
On listings returned from UNIX FTP servers, only the hour and minute of the
modification time of a given FTPFile is shown. UnixFTPEntryParser.java does the
following when encountering such a listing:
Calendar cal = Calendar.getInstance();
cal.set(Calendar.SECOND, 0);
cal.set(Calendar.MINUTE, 0);
cal.set(Calendar.HOUR_OF_DAY, 0);
try
{
int pos = MONTHS.indexOf(mo);
int month = pos / 4;
if (null != yr)
{
// it's a year
cal.set(Calendar.YEAR, Integer.parseInt(yr));
}
else
{
// it must be hour/minute or we wouldn't have matched
int year = cal.get(Calendar.YEAR);
// if the month we're reading is greater than now, it must
// be last year
if (cal.get(Calendar.MONTH) < month)
{
year--;
}
cal.set(Calendar.YEAR, year);
cal.set(Calendar.HOUR_OF_DAY, Integer.parseInt(hr));
cal.set(Calendar.MINUTE, Integer.parseInt(min));
}
cal.set(Calendar.MONTH, month);
cal.set(Calendar.DATE, Integer.parseInt(da));
file.setTimestamp(cal);
Unfortunately, the code does not properly set the MILLISECOND field of the
original Calendar object. This means the MILLISECOND field is dependent upon the
system time that the object is actually created. Therefore, the FTPFile's
timestamp is wrong.
I propose that the above code be patched to add a cal.set(Calendar.MILLISECOND, 0);