commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oberhuber, Martin" <Martin.Oberhu...@windriver.com>
Subject RE: [NET] 1.5 Leap year processing
Date Sun, 16 Mar 2008 13:00:47 GMT
Hi Sebb,

Thanks for your patch, I was not aware that it had not yet been applied.
Thanks also for the new Feb29 testcases.

> 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.

Ok, I applied the patch and it's good for the Feb.29 scenario.
But I found a different problem with dates on Jan.1 when
The client computer still has Dec.31 -- which can happen 
Due to time zone differences. The problem existed in the
Old code as well so it's not new with your patch.

Anyways, I commented on Jira so let's follow up discussions there.
   https://issues.apache.org/jira/browse/NET-188

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: sebb [mailto:sebbaz@gmail.com] 
> Sent: Samstag, 15. März 2008 02:34
> To: Jakarta Commons Developers List
> Subject: Re: [NET] 1.5 Leap year processing
> 
> 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...
> >
> 
> 
> >
> >  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
> 
> 

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


Mime
View raw message