commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [NET] 1.5 Leap year processing
Date Sat, 15 Mar 2008 01:33:40 GMT
On 14/03/2008, Oberhuber, Martin <Martin.Oberhuber@windriver.com> wrote:
> Hi Sebb,
>
>
>  > Regex is not available in Java 1.3.
>  > Also, how does one know where the year is in the string?
>
>
> Code for this already is in Commons Net, using ORO for the Regex.
>  See UnixFTPEntryParser.java line 105

OK, did not realise that it used ORO.

>
>  > 2.2 If previous year also gives a parse error then give up?
>
>
> Hm... Well, well. The point is that we don't have a chance to
>  get it right 100%. There's just too much that can go wrong,
>  for instance:
>
>   * Dates are in server local time, but we don't know what
>     "current time" the server thinks it has. Its clock could
>     be off by years in the worst case, making all tries to
>     correctly parse short date impossible.
>
>   * We don't know the server time zone for sure
>
>   * Time in the client is currently used for substituting
>     current year, but that one could also be wrong.

Yes.

>  So - I think I'd like to give it a chance with the current year
>  and the previous year, and if both fail than create an entry
>  With a "null" date (1.1.1970 or something like that).

I think the date should really be null if it cannot be determined.

>  Also noticed that my algorithm fails in the case where due to
>  time zone differences, the client computer still has local
>  year nnnn but server already has nnnn+1.
>
>  Unfortunately I don't have time right now to code a patch,

I've already added a patch that works for most cases.

>  I guess that talking about code would be better than talking
>  about concepts at this point. That being said, I don't find
>  Rory's current patch that bad that it justifies further
>  Holding off the release.
>
>  The patch code only strikes when the previous version's code
>  Would run into a parse exception, and it seems to correctly
>  Handle the Feb.29 case... So I'm not sure what else is missing
>  That must go into a 1.5 release...
>

The current code does not fix NET-188 for Java 1.3 and 1.4, which NET
1.5 is supposed to support.

The problem is that the 1.3 and 1.4 Java RTLs don't generate a syntax
error for Feb 29 1970; instead they convert it to Mar 1 1970; the code
then replaces 1970 with the current (or previous) year. So the
timestamp appears to parse OK, but is incorrectly parsed.

The patch I posted recently does work for 1.3+, but does not support
short dates more than about 10 months old.

>
>  Cheers,
>  --
>  Martin Oberhuber, Senior Member of Technical Staff, Wind River
>  Target Management Project Lead, DSDP PMC Member
>  http://www.eclipse.org/dsdp/tm
>
>
>
> ---------------------------------------------------------------------
>  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