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 23:43:49 GMT
On 11/03/2008, Rory Winston <rory.winston@gmail.com> 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 <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
> >
> >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

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


Mime
View raw message