On Tuesday 28 September 2004 7:11 am, Rory Winston wrote: > 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.
Me too. > > -----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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
