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 te
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 finally have sufficient free time to begin implementing what we talked
about in this conversation several months ago :
http://nagoya.apache.org/eyebrowse/SearchList?listId=&listName=commons-dev%40jakarta.apache.org&searchText=%22Designing+a+Date+Format-aware+FTP+Entry+Parser%22&defaultField=subj
Steve Cohen schrieb:
I guess I don't have a problem with making a composite parser, which you could
make the default for VFS if it works, but I don't think it can be the default
for NetComponents itself.
re composite parser: You can stick this work on me as soon as the
framework has materialize
On Thursday 30 September 2004 7:09 am, Mario Ivankovits wrote:
> Steve Cohen wrote:
> >This business of constantly churning does bother me.
>
> I hope I dont leave to negative impressions on you.
I didn't mean to leave such an impression.
>
> If we find an agreement it could be possible with the
[NET] Designing a Date Format-aware FTP Entry Parser
Steve Cohen wrote:
>This business of constantly churning does bother me.
>
I hope I dont leave to negative impressions on you.
If we find an agreement it could be possible with the way you build the
framework - it is good enough for me.
Steve Cohen wrote:
This business of constantly churning does bother me.
I hope I dont leave to negative impressions on you.
If we find an agreement it could be possible with the way you build the
framework - it is good enough for me.
---
Mario
---
On Thursday 30 September 2004 5:39 am, Mario Ivankovits wrote:
> Steve Cohen wrote:
> >First parser to successfully parse every
> >item in the listing I suppose. Or do you go for best score?
>
> line-by-line - the first parser which is able to parse should be cached
> (ad performance) - that way
Steve Cohen wrote:
>First parser to successfully parse every
>item in the listing I suppose. Or do you go for best score?
line-by-line - the first parser which is able to parse should be cached
(ad performance) - that way it might be only slower on the first match
However the parser should be pre
On Wednesday 29 September 2004 2:27 pm, Mario Ivankovits wrote:
> Steve Cohen wrote:
>
> Maybe you are right, but at least I think it should be possible to
> implement a "CompositeDateFormat".
> This could be a composite of n languages and it tries every (configured
> - by default eg. US, FR, DE)
Steve Cohen wrote:
The advantage of 2 is that you still get a Date object after all your pains,
more easily that you do from rolling your own off a regex. And it's easier
to use SimpleDateFormat format strings than regular expressions. Finally,
there is more calendar logic in SimpleDateFormat
Steve Cohen wrote:
If you think that I meant for the user to pass in FTPDateFormat objects, you
misunderstood me. The paradigm I want to use here is passing in strings.
No, i got it. But maybe we could do it like the FTPFileEntryParser do?
Try to determine if the use passed a FQCN else treat
On Tuesday 28 September 2004 7:34 am, Mario Ivankovits wrote:
> Steve Cohen wrote:
> >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
On Tuesday 28 September 2004 8:02 am, Mario Ivankovits wrote:
> Steve Cohen wrote:
> form jui 7
> rather than
> 7 jui
>
> Steven, we have a problem?
Yes indeed. Thanks! Ouch!
>
> I have tried to parse the date you shown in your ftp-locales test.
>
> SimpleDateFormat sdf = new
Steve Cohen wrote:
form jui 7
rather than
7 jui
Steven, we have a problem?
I have tried to parse the date you shown in your ftp-locales test.
SimpleDateFormat sdf = new SimpleDateFormat("MMM dd", new
Locale("fr", "FR"));
Date dt = sdf.parse("jui 7");
"jui 7" is not parseabl
Steve Cohen wrote:
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
l 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 Forma
ginal 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:
> &
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
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 u
Designing a Date Format-aware FTP Entry Parser
After having percolated on the back burner for several years as an unresolved
issue, there is finally some momentum toward solving the problem of parsing
FTP entries from servers which format the file timestamps in the directory
listings in a forma
21 matches
Mail list logo