IWhen you first wrote me about the numeric date I assumed that the new system just happened to handle it, without bothering to look at the regex that decided what the date parser must parse. Then when I hadn't heard from you for awhile, I thought we were over this hump.
But yes, this is a problem, and it looks as if Rory's fix is a good one. I will add some junit test cases to verify this.
Neeme Praks wrote:
AFAIK, the new system uses both: regexp for extracting the timestamp from the entry line and then using DateFormat to parse that.
Example:
-rw-r--r-- 1 1000 1000 27 Jan 24 11:31 messages.vsp
from this line the regexp extracts the timestamp part ("Jan 24 11:31") and then DateFormat is used to parse this to a valid Date object.
The issue here is that the failure is already at regexp matching, and the code never reaches the DateFormat parsing part.
I'll try to check out Rory's changes during the weekend.
Rgds, Neeme
Steve Cohen wrote:
No, that's not it at all. Remember that the new system does not use Regexes for date parsing, it uses SimpleDateFormats. From Mr. Praks' descriptions, I am assuming he's now running the 1.3 or earlier versions, which do use regexes.
This surprises me because I've had several conversations with him over the past month in which the new system was discussed. Perhaps he forgot to specify the date format as "yyyy/MM/dd" in his FTPClientConfig this time? Or perhaps his code is finding an older commons-net.jar than he was expecting?
Steve Cohen
Rory Winston wrote:
Right, the problem with this format is that the date is not composed of three discrete components (from a regex POV), but two. Basically what we will need to do is expand the regex to handle thuis - can you give me details of the FTP server operating system and FTP server software version if you have it please.
Cheers Rory
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
