Hi all, regarding FTP parser date +-6 month problem:
Having a look at http://www.ietf.org/rfc/rfc3659.txt?number=3659 section 3 it seems that there is a standardization effort in place to finally get time values right for FTP (proposed standard "MDTM" command. So this is what we'll want to have in the future to get 100% correct dates. And this is what clients could potentially use if a server supports it and the normal ftp parser returns a "null" date due to parsing problems. Check availability of this feature on the server with: ftp> literal syst 215 UNIX Type: L8 ftp> literal feat 211-Features: EPRT EPSV MDTM PASV REST STREAM SIZE TVFS 211 End ftp> Also, there will be MLST and MLSD for machine listing to get rid of the problems with LIST / DIR commands (see section 7 of RFC3659). That being said, my point is that if a server doesn't support the MDTM command and the LS output of "dir" is ambiguous, there is not much point in guessing and doing it one way or the other. I really don't care much about whether dates upto 6 months in the future are returned as future or back, though I have a slight preference for not dealing with future dates too much since they are a corner case. One day in the future is fine since it can happen due to time zone differences, but not more. Who would consciously create a file in the future? If in doubt, the MDTM command is the way to go for disambiguating. And the FTPClient should not send the command itself but allow the client to send it, if client thinks that exact times are required. About anything else in the DIR output, the FTP standard says: http://www.ietf.org/rfc/rfc0959.txt?number=959 LIST: "Since the information on a file may vary widely from system to system, this information may be hard to use automatically in a program, but may be quite useful to a human user." So summing up: I'm in favor of only allowing 1-day-in-the-future dates and rolling back all others; but I really don't care a lot since the way to go is standardized commands for machine processing. Cheers, -- Martin Oberhuber, Senior Member of Technical Staff, Wind River Target Management Project Lead, DSDP PMC Member http://www.eclipse.org/dsdp/tm > -----Original Message----- > From: Rory Winston [mailto:[EMAIL PROTECTED] > Sent: Dienstag, 11. März 2008 21:10 > To: Jakarta Commons Developers List > Subject: Re: [NET] fixing short date parsing problems (was: > [VOTE] Release Commons Net 1.5) > > Sebb/Martin > > The lenient future dates flag just allows a window of +1 day in the > short timestamp, which if > now(), will not be rolled back by a year. > This is to prevent dates slightly in the future being rolled back > inappropriately. You keep mentioning the +/- 6 month thing - > the problem > is that this (like a lot of other FTP stuff) isn't a standard and you > can't depend on it. Still, there are a bunch of other flags > in there to > work around other issues, so maybe another flag might be required for > fully comprehensive date handling. > > Say if we have a date d ( 1 day < d <= 6 months) in the future, this > flag would control whether d is rolled back (as it would be > now) or kept > in the current year (which we would need a flag for). > > Is this what is needed to get the remaining tests to pass? > > Rory > > sebb wrote: > > On 10/03/2008, sebb <[EMAIL PROTECTED]> wrote: > > > >> On 10/03/2008, Rory Winston <[EMAIL PROTECTED]> wrote: > >> > Hi Sebb > >> > > >> > A couple of things: > >> > > >> > 1. Which tests are you referring to in your first point below? > >> > >> > >> > testFeb29IfLeapYear(org.apache.commons.net.ftp.parser.FTPTimes > tampParserImplTest) > >> > testFeb29LeapYear(org.apache.commons.net.ftp.parser.FTPTimesta > mpParserImplTest) > >> > >> The first one only applies in leap years - it was > designed before the > >> addition of the server calendar parameter. It could perhaps be > >> dropped. > >> > >> I've since fixed the following test, and it also fails, > but only on 1.4: > >> > >> > testFeb29NonLeapYear(org.apache.commons.net.ftp.parser.FTPTime > stampParserImplTest) > >> > >> > >> > 2. Does the assumption have anything to do with the > lenientFutureDates > >> > flag in FTPTimestampParserImpl? > >> > > >> > >> > >> Yes, the *nix future dates thing is tied in with > lenientFutureDates. > >> > >> I suspect there may need to be a new flag which enables > *nix style +/- > >> 6 months dates. > >> > >> I don't understand what the lenient flag is about - was > it part of an > >> attempt to handle *nix dates (in which case it's wrong, as lenient > >> allows up to 1 year in arrears), or is it for different OSes? > >> > >> The past and future date tests need extending as well; > there should be > >> one test where the current date is in the first 6 months > of the year, > >> and another where it is in the second 6 months of the year (and > >> perhaps leap/non-leap years too). > >> > >> > > > > The past and future tests have been updated as above. > > > > The future tests fail on both trunk and 2.0. > > However, the cases where they apply are relatively rare, so fixing > > them could be left until a later release. > > > > The Feb 29 failures definitely need to be fixed before > trunk is released. > > > > It seems to me that there will probably still be some valid > edge cases > > where the date validation fails. AIUI at present this would > mean that > > the entire entry is set to null. > > > > Seems to me it would be a lot better if the FTPFile entry was still > > generated, but with a null date. > > > > Not all users need the dates, so this would allow Net to > fail more gracefully. > > > > > >> > Rory > >> > > >> > > >> > sebb wrote: > >> > > I've committed updates to the > FTPTimestampParserImplTest classes in > >> > > trunk and NET_2_0. > >> > > > >> > > The 2 additional tests for Feb 29 fail on Java 1.3/1.4. > >> > > > >> > > Both trunk (Java 1.3/1.4) and NET_2_0 (Java 1.5+) > now fail on short > >> > > dates that fall in a different year from current > (previous or next). > >> > > > >> > > Some of the existing tests assume that dates cannot > be more than 1 > >> > > hour in the future - IMO this is wrong - so I > propose to drop these > >> > > tests. > >> > > > >> > > I'm working on a patch which I'll add as a patch to NET-188. > >> > > > >> > > On 09/03/2008, Rory Winston <[EMAIL PROTECTED]> wrote: > >> > > > >> > >> Sure, you can just add them directly yourself if you like. > >> > >> > >> > >> Rory > >> > >> > >> > >> > >> > >> The *nix short date formatting fixes don't > currently have any tests, > >> > >> at least when I last checked. > >> > >> > >> > >> I think these need to be added first. > >> > >> > >> > >> I can add some later today if that's OK with you? > >> > >> Or do you want them done as patches via Jira? > >> > >> > >> > >> > >> > >> On 09/03/2008, Rory Winston <[EMAIL PROTECTED]> wrote: > >> > >> > Hi James > >> > >> > > >> > >> > Yes, I'm going to cut new RCs for 1.5 and 2.0. > >> > >> > > >> > >> > Thanks > >> > >> > > >> > >> > Rory > >> > >> > > >> > >> > > >> > >> > >> <snip/> > >> > >> > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
