ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 34941] - FTP uptodate calculations wrong
Date Sat, 21 May 2005 22:15:42 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=34941>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34941


scohen@apache.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |stevel@apache.org




------- Additional Comments From scohen@apache.org  2005-05-22 00:15 -------
I previously stated that I think that your problem results from a new bug.  I no
longer think so.  It's not a bug.

First of all the preserveLastModified is documented as only apply to gets, not
puts, as I previously stated, but that is irrelevant.

More importantly, you must consider timestamp resolution differences between
your local machine and the ftp server.  Even if they are on the same box,
commons-net-ftp, since it must work through directory listing formats, is
restricted to what is displayed by an FTP listing, typically, HH:mm.  Whereas
your local file system more than likely provides second resolution.  Therefore,
even if serverTimeZoneConfig is specified, the timediffmillis attribute must
also be specified, not to account for the time zone differences but to account
for the granularity difference.  A value of 60000 must be set here.

I'm not sure I'm happy with this situation, but with the fix I've checked in the
task is now performing as currently documented.  The timediffmillis attribute is
becoming more of a messy "slush fund" as it handles both time zone differences
and timestamp granularity issues.  Using time zones is much better than using
timediffmillis to handle this (since you can let java "do the math", and more
importantly, because it understands daylight savings time, which timediffmillis
does not.)  The only good use left for timediffmillis is to handle granularity
issues.  I think we should think about deprecating timediffmillis in favor of an
attribute that takes some predefined granularity constants such as
"MINUTE_GRANULARITY", etc. which the task can translate into milliseconds.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message