commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <p...@steitz.com>
Subject Re: lang.time.* Was: [VOTE] Release of Commons Lang 2.0
Date Mon, 19 May 2003 02:52:44 GMT
Henri Yandell wrote:
> Two questions basically.
> 
> 1) Should lang contain time related code?
> 
> 2) Is there anything in lang.time which should not go in Lang 2.0?
> 
> My vote:
> 
> 1) Yes. As always I believe that code should mature out of Lang unless it
> is large enough to be kicked out before birth. Joda Dates,
> http://www.joda.org, helps avoid a need for one aspect of a Commons Time
> and as lang.time grows it could form the basis of another Commons Time, or
> the bits that don't fit could.
> 
> 2) DateUtils needs splicing and dicing or just removing.
> 
>   i) Various parts are DateFormat related, providing 'standard' patterns.
>  ii) Some DateFormatUtils classes to ease conversion.
> iii) Limited method to format elapsed millisecond time.
>  iv) Calculate phase of moon for a given date.
>   v) format Date for SMTP header
> 
> None of these seem right for Lang.time and I would like us to just release
> CalendarUtils/StopWatch/FastDateFormat.

FWIW, I agree, assuming that these are ready for release (or very 
close).  I agree with Gary that StopWatch in particular is a very useful 
utility that it would be a shame to lose.

Phil

> 
> Hen
> 
> On Sun, 18 May 2003, Gary Gregory wrote:
> 
> 
>>Hello,
>>
>>StopWatch is a great doo-dad, which I use, it'd be a shame to loose it. Are
>>we talking about discussing a .lang.time vs. a new commons-time? If not,
>>could we just decide which classes are (not) ready?
>>
>>Gary
>>
>>-----Original Message-----
>>From: Henri Yandell [mailto:bayard@generationjava.com]
>>Sent: Sunday, May 18, 2003 15:19
>>To: Jakarta Commons Developers List
>>Subject: lang.time.* Was: [VOTE] Release of Commons Lang 2.0
>>
>>
>>
>>On Sun, 18 May 2003, Serge Knystautas wrote:
>>
>>
>>>Henri Yandell wrote:
>>>
>>>>lang.time is not ready yet.
>>>
>>>What's left to be done here?  I had submitted some of this right as 1.0
>>>was being released and was expecting it would be included in the next
>>>major release.  I was off this list for a bit, so was it discussed and
>>>rearranged?
>>
>>Thanks for making me try to figure out why lang.time has been off the 2.0
>>release schedule since the beginning. Looking back at the mails, I think
>>it is because there was the usual debate over whether lang.time should be
>>in Lang or in Commons Time. Where does the end of lang.time's scope get
>>drawn.
>>
>>Currently lang.time is made up of 4 classes, all from different
>>developmers.
>>
>>Serge's CalendarUtils is devoted to providing improved functionality for
>>Calendar objects, and through them Dates.
>>Ant's DateUtils has a few methods for Dates, but probably should be
>>wrapped into CalendarUtils/DateFormatUtils.
>>FastDateFormat is an improved rewrite of SimpleDateFormat taken from the
>>TreeTrove project.
>>StopWatch is a time utility for recording periods of time. Mainly I find
>>this useful for benchmarking.
>>
>>All have unit tests.
>>
>>I'm quite confident that CalendarUtils and StopWatch fit nicely in
>>lang.time. FastDateFormat too unless a Commons Text component were to
>>arrive. DateUtils I think should be broken up/folded into CalendarUtils.
>>
>>The biggest reason for not having lang.time in the release is that it
>>still needs debate. So the question is:
>>
>>Should we work on lang.time before 2.0? How much work is in there? There's
>>a Bugzilla issue for improvements to StopWatch. DateUtils needs
>>butchering [imo anyway]. Anything else?
>>
>>Additionally, would there be any versioning issues with lang.time
>>appearing in Lang 2.1?
>>
>>Hen
>>
>>
>>---------------------------------------------------------------------
>>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