commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [NET] fixing short date parsing problems (was: [VOTE] Release Commons Net 1.5)
Date Tue, 11 Mar 2008 12:46:15 GMT
On 10/03/2008, sebb <sebbaz@gmail.com> wrote:
> On 10/03/2008, Rory Winston <rory.winston@gmail.com> 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 <rory.winston@gmail.com> 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 <rory.winston@gmail.com> wrote:
>  >  >>  > Hi James
>  >  >>  >
>  >  >>  >  Yes, I'm going to cut new RCs for 1.5 and 2.0.
>  >  >>  >
>  >  >>  >  Thanks
>  >  >>  >
>  >  >>  > Rory
>  >  >>  >
>  >  >>  >
>
>
> <snip/>
>

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


Mime
View raw message