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
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
I finally have sufficient free time to begin implementing what we talked
about in this conversation several months ago :
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
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
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 it
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
] 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.
---
Mario
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 way
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
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)
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
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
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
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
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 parseable!!
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 SimpleDateFormat(MMM
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 date
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
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
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
21 matches
Mail list logo
