------- Additional Comments From [hidden email] 2005-06-05 14:23 -------
OK - we're in uncharted waters here and I am not entirely sure what is the right
thing to do.
Daniel Savarese, the original author of this code base does not remember the
reasons for his original code which was more tolerant but not completely so of
the client and server clocks being out of synch.
The current implementation is more "accurate" but at the cost of being
completely intolerant of "slop".
I could for example, without too much trouble, recode this so that any server
timestamps that appear to be more than one day in the future be considered last
year. That would handle this for all timezones in the world as well as slop,
and it may be the most faithful rendition of what appears to be Daniel's
original intent. But I'm still uncomfortable introducing inaccuracies to
account for slop, unless I can be reasonably sure it's harmless.
Mr. Ishigami: I need more information from you.
1) Can you tell me your exact use case? Are you having this problem because
a) the clocks are out of synch and you could fix the problem
b) the clocks are out of synch but you can't do anything about it beacuse the
server is out of your control?
c) the server is in a different time zone from the client which you could handle
by using FTPClientConfig?
2) Please indicate whether you have any information other than observation that
says that the rollover from MMM dd HH:mm to MMM dd yyyy display occurs when a
file becomes six months old.
Parenthetically, I'll note that this whole business is a powerful argument in
favor of those FTP servers, such as the one that Neeme Praks indicates is now
standard on Debian GNU Linux (not to mention Windows), which display all
timestamps as yyyy-MM-dd HH:mm, instead of making us guess.