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... > 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
