Steve, 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 [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
