commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven Caswell" <st...@mungoknotwise.com>
Subject RE: [lang] DateUtils.parseCVS
Date Tue, 06 Jul 2004 22:59:59 GMT
Sounds like we should just rip the parseCVS code and send it to the bit
bucket. Anyone care if I just yank the currently commented out code?


Steven Caswell
Sun Certified Java Programmer
steve@mungoknotwise.com
"War is an ugly thing, but not the ugliest of things. The decayed and
degraded state of moral and patriotic feeling that thinks that nothing is
worth war is much worse. The person who has nothing for which he is willing
to fight, nothing which is more important than his own personal safety, is a
miserable creature and has no chance of being free unless made and kept so
by the exertions of better men than himself." .... John Stuart Mill.


> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com] 
> Sent: Tuesday, July 06, 2004 2:57 PM
> To: Jakarta Commons Developers List
> Subject: Re: [lang] DateUtils.parseCVS
> 
> 
> That'll be http://joda-time.sourceforge.net  which I look 
> after ;-) But that tackles different issues.
> 
> At present I'm -1 on parseCVS. Its an ant utility, not a lang 
> one. Stephen
> 
> ----- Original Message -----
> From: "Gary Gregory" <ggregory@seagullsoftware.com>
> I did not know about SMTP. IMHO, this does not sound like it 
> belongs in [lang] either but rather in [email].
> 
> The subject of providing better date/time handling is a large 
> one. These methods might not fall in that category but FYI, I 
> once asked on this list and I was pointed to a non-apache 
> library that seems quite complete. Can't recall the name now though.
> 
> Gary
> 
> > -----Original Message-----
> > From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> > Sent: Monday, July 05, 2004 15:48
> > To: Jakarta Commons Developers List
> > Subject: Re: [lang] DateUtils.parseCVS
> >
> > We already have formatting of SMTP in [lang], so this could 
> be viewed
> as
> > just another commonly used product. That said, I'm not sure what the
> use
> > case of this is (useful to ant yes, but to lang maybe not)
> >
> > If we do include it, DateFormatUtils seems a likely location, as 
> > formatting/parsing go together normally.
> >
> > Stephen
> >
> > ----- Original Message -----
> > From: "Gary Gregory" <ggregory@seagullsoftware.com>
> > I am not that crazy with anything of the form 
> "parseProduct". What if 
> > there was, or surely going to be 2, then 10 such methods 
> for CVS. Then
> a
> > CvsUtils or some such class would be better. Does this belongs in a 
> > separate class if not in the sandbox?
> >
> > 2c,
> > Gary
> >
> > > -----Original Message-----
> > > From: Steven Caswell [mailto:steve@mungoknotwise.com]
> > > Sent: Monday, July 05, 2004 08:23
> > > To: commons-dev@jakarta.apache.org
> > > Subject: [lang] DateUtils.parseCVS
> > >
> > > Regarding issue
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=22172, I
> > > seem to recall that parseCVS was omitted in 2.0 primarily 
> due to not 
> > > having an answer about parsing a format such as "h:mm z". 
> Since cvs 
> > > doesn't
> > parse
> > > a
> > > time in this format, I propose that parseCVS not be able 
> to parse it 
> > > either, but throw an exception instead. With this change, 
> I propose 
> > > we
> include
> > > parseCVS in 2.1.
> > >
> > >
> > > Steven Caswell
> > > Sun Certified Java Programmer
> > > steve@mungoknotwise.com
> > > "War is an ugly thing, but not the ugliest of things. The decayed
> and
> > > degraded state of moral and patriotic feeling that thinks that
> nothing
> > is
> > > worth war is much worse. The person who has nothing for 
> which he is 
> > > willing to fight, nothing which is more important than his own 
> > > personal
> > safety, is
> > > a
> > > miserable creature and has no chance of being free unless made and
> > kept so
> > > by the exertions of better men than himself." .... John 
> Stuart Mill.
> > >
> > >
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: 
> commons-dev-help@jakarta.apache.org
> >
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> >
> >
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
> 
> 
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message