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