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 Sep 2004 23:08:04 GMT
Where I was sort of heading was a combination of these, since I'm still not 
sure that server locale implies a particular date format.  It maybe defines 
month abbreviations and the ordering of day, month, and year within a date, 
but does it define whether a numeric-only date format, as opposed to an 
abbreviated month is used?  I don't think so, and I'm not sure that anything 
forces an ftp server to format its listings in the locale-specific way.

This brings back to the FTPDateFormat object which I see as a place to resolve 
all this uncertainty and ambiguity.  And a factory to aid in the creation

public static FTPDateFormat FTPDateFormatFactory.createFTPDateFormat(
	Locale locale, 
	SimpleDateFormat newerThanOneYear, 
	SimpleDateFormat olderThanOneYear)

I see default static final FTPDateFormat objects for each of the locales so 
that another, simpler factory method could create those

public static FTPDateFormat FTPDateFormatFactory.createFTPDateFormat(
	Locale locale)

this would return the static object we created as the default for that locale.
This would probably be the preferred way to access it.

I would be very conservative in trying to automate this - I would, in fact, 
not do so in the first release.  My goal in the first release would be to 
implement all this stuff but have all current implementations work as before.

We simply have no idea of the relative prevalence of arrangements in the real 
world at this time.  But we should devote some effort to defining the way of 
accessing this functionality that is as painless for the user as possible.

Then when complaints came in, we would have something to recommend which is 
better than having nothing to recommend.

On Sunday 26 September 2004 1:51 am, Mario Ivankovits wrote:
> Steve Cohen wrote:
> >and delegate the task of parsing it to a pair of
> >SimpleDateFormat objects (one for less than 1 year old and the other for
> > one year old or older), each constructed on the basis of a format string
> > and a locale.
> Sounds good at all, just one additional question: How should the user
> pass in these date parsers?
> 1) explicitly set the date parser per connections
> But this might work against the idea behind the default file entry parser.
> The default file entry parser uses some "magic" to decide the real
> parser and hide the pain about the different styles from the user.
> Depending on the result the possible date formats could be known too
> (except for the locale for sure).
> If the user needs to set a real date parser implementation he always has
> to take the result of the DefaultFileEntryParser into account.
> This brings me to
> 2) only set a java.util.Locale per connection
> and pick the needet date parser - in combination with the result of SYST
> - out of a date parser pool.
> For sure - it should be possible to do 1) but this should not be the
> preferred way.
> ---
> Mario
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message