On 11/03/2008, Rory Winston <[EMAIL PROTECTED]> wrote: > Sebb/Martin
Martin and I agree on wanting the parser to return an FTPFile rather than null for the cases where the date (etc ?) does not parse OK. I would like to see this go into the next release of NET 1.5 and 2.0; I think this will avoid a lot of future problems. Martin has yet to express an opinion about the +/- 6 month issue, as far as I know. > 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. But why should they be rolled back by a year? Is it documented behaviour in any FTP implementations that dates in the past year are displayed without the year? If so, which implementations? > This is to prevent dates slightly in the future being rolled back > inappropriately. That much I agree with. > 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. It does seem to be true for at least some *nix systems, and "man ls" (which is where FTP seems to take its lead) specifically describes this behaviour. I've tried it on FreeBSD, and FTP does behave this way there. I hope to try it on HP-UX and Ubuntu soon. > 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). Not necessarily the current year - it could be the next year if the current date is in the second half of the year. > Is this what is needed to get the remaining tests to pass? Yes - but as I wrote in a previous e-mail, this could be left for later if required. It should not often happen. What is vital for the release of 1.5 is fixing the Feb 29 problem. > 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.FTPTimestampParserImplTest) > >> > >> testFeb29LeapYear(org.apache.commons.net.ftp.parser.FTPTimestampParserImplTest) > >> > >> 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.FTPTimestampParserImplTest) > >> > >> > >> > 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]
