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:[EMAIL PROTECTED] > 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 > <[EMAIL PROTECTED]> 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: [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]
