commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Cohen <>
Subject Re: [net] Designing a Date Format-aware FTP Entry Parser
Date Sun, 26 Dec 2004 15:12:50 GMT
Rory -
Congratulations.  I don't know how I missed the announcement of 1.3.
Well, yes, actually, I do see.  It didn't have a [net] in the title 
which is what my filter is looking for.  Anyway, thanks for your hard work.

I'm not finished yet, but it really doesn't look hard, once you sink 
your teeth into it.

I think there work out to be three settable parameters:
1. SimpleDateFormat string for dates older than 1 year
2. SimpleDateFormat string for dates newer than 1 year
3. A delimited string of month abbreviations to replace the default ones 

The regular expressions would see their current 
month/day/year/hour/minute groups replaced by
(\\S+\\s+\\S+\\s+\\S+)\\s+, creating a single string forwardable to the 
timestamp parser.

I have a nagging question about time zones.  My suspicion is that there 
is no standard about of time zone usage under FTP and that the time zone 
in use on a particular server may not be automatically knowable to the 
user.  This will come into play with files that are within +/- 24 hours 
of a year old.  On the other hand, if our main use case is private FTP 
servers that the coder has reason to connect with rather than an 
all-purpose FTP tool, the time zone used is knowable to such a user and 
could also be a parameter, with perhaps GMT or the user's time zone used 
as a default (which?).  The parameter would simply be one of the 
java.util.TimeZone ids, such as "America/New_York" or "GMT".

Aside from that, the more difficult issues are
1. packaging.  Are we REPLACING the current parsers with localizable 
models or offering the localizable models as an alternative.  My 
preference is for the former as the whole deprecation/removal business 
under Jakarta rules tends to be difficult.  Much better to think this 
through beforehand than to have to undergo unnecessary deprecation later.

2. factory issues.  This is really the key to the whole thing.  What I 
absolutely don't want is a further combinatorial explosion of 
FTPClient.listFiles() methods.  The factory methods for creating parsers 
would have to become the default methods.   They would of course need 
sensible default values.  They would fit well with clients such as Ant.


Rory Winston wrote:
> Hi Steve,
> I pushed out 1.3 in December - I think we agreed back then that the date formatting issue
would be sufficiently large to necessitate waiting for a later release. 
> Coincidentally, I made a start at the extensible date parser as well, using a solution
based on a SimpleDateFormat object. I would be very interested to see what you have come up
with, so we can compare notes. I have kept the changes local as well, but maybe after we collaborate
on this a little bit, we can start to patch into HEAD. 
> I'm stuck behind a narrowband connection for the next week or so, and will have only
intermittet net access, but after next week I can get back into it again.
> Cheers (and happy xmas),
> Rory
> "Jakarta Commons Developers List" <> wrote:
>>I finally have sufficient free time to begin implementing what we talked 
>>about in this conversation several months ago :
>>How is the push to 1.3 release going?  I don't want this release held up 
>>for this, as I still have little or no idea how long it will take to 
>>develop this implementation but neither do I want to interfere with it, 
>>so I may keep my implementation local for the time being.
>>To unsubscribe, e-mail:
>>For additional commands, e-mail:
> _________________________________________________________________
> Sign up for eircom broadband now and get a free two month trial.*
> Phone 1850 73 00 73 or visit
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message