commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rory Winston" <>
Subject RE: [NET] Designing a Date Format-aware FTP Entry Parser
Date Tue, 28 Sep 2004 12:11:06 GMT

This sounds like it could be the way forward. This way, the user doesn't have to specify anything
extra unless they really need to. The only question is, do we generate regexes on the fly,
or pull out the enire date string? I would be inclined to go for the latter option.

-----Original Message-----
From: Steve Cohen []
Sent: 28 September 2004 12:24
To: Jakarta Commons Developers List
Subject: Re: [NET] Designing a Date Format-aware FTP Entry Parser

On Monday 27 September 2004 7:50 am, Mario Ivankovits wrote:
> Steve Cohen wrote:
> >I created a hypothetical French user
> >named Jacques on my system, gave him "LANG" of "fr_FR", logged in as him,
> > and got French directory listings, although the dates were of the form
> > jui 7
> >rather than
> >7 jui
> So it is as i thought - at least for the unix like ftp server. The date
> format isnt really true locale-specific, only the month name is converted.
> I am not sure if it is worth to implement the whole date stuff just to
> handle the month name - we could achieve the same by simply provide a
> static month-name list and a
> static addMonth(String name, int number) which one can use to add some
> month-names we do not maintain in our default list.

Locale + SimpleDateFormat provides an easier way to do this.  A 
SimpleDateFormat is constructed with the Locale as a parameter and then 
SimpleDateFormat.getShortMonthNames() provides a list of month abbreviations 
for that locale.

Another option, though, is NOT to use regular expressions for the date parsing 
at all.  Let the regex pull out the entire date portion and then parse that 
with the SimpleDateFormat.

> This is fairly easy to implement.
> But i dont know what Rory found for NT and therefore i dont know if this
> might work there too.
> >It seems to me that we might need no other identifier than Locale.  I
> > would caution once again that we not get this mixed up with SYST.  I
> > would proceed for now as though there is no way to automate this.  Later
> > if we find such a way we can build for it.
> But you found that the french date wasnt relly printed in its typical
> manner, maybe another server will do.
> So it is possible you might end up in two French locale definitions and
> then the user has to encode this fact into the locale name e.g "fr_FR"
> and "fr_FR_xyzserver".
> For sure, in this case my proposed solution might not work too.
> The question is: Are there server where the date parts are really
> printed in different order depending on the locale?

That is not what I meant when I said we might need no other IDENTIFIER than a 
locale.  That is, if the user supplied "fr_FR" we would construct a 
SimpleDateFormat("MMM dd", new Locale("fr", "FR")) 
and if he supplied "en_US" we would construct thus:
SimpleDateFormat("MMM dd", new Locale("en", "US")) 

That is to say, we would NOT infer date-month-year ordering from the locale, 
at least for the unix-like parsers.

But there would be a way for the user to supply the date format string as well 
as locale so as to get
SimpleDateFormat("dd MMM", new Locale("fr", "FR")) 
if it is required.

All this setting would go on as setters on a factory class that the user would 
not have to use.  If they didn't setLocale, en_US would be the default. If 
they setLocale but not either date recent or older date format, then the 
standard US ordering would be used but the Locale month names.  If they 
specified Locale and older date format, we could infer the newer date format 
as well.  And if they specified everything, we could handle that case too.

> What date problems do have users reported till today?
> Acutally i only read the aix language problem (and seen your french test).

We seem to see one or two of these a year.

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

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

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

View raw message