commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <ggreg...@seagullsw.com>
Subject RE: [lang].time.* Was: [VOTE] Release of Commons Lang 2.0
Date Mon, 19 May 2003 16:47:36 GMT
After a little more reading, it really seems to me that in the long term
.lang.time (or commons-time) is a good idea:

(1) (self-serving) We are adjusting all of our XML I/O dates to be XML
Schema-compliant dates which means using ISO dates.

(2) Sun's reefer (Bug ID 4340168) on fixing dates is oh so lame: do nothing.
Nothing will happen for Java 1.5. Who knows if ever! Not to mention that due
to other things, our apps are 'stuck' on JRE 1.3.1.

(3) (2) -> an opportunity for commons-lang to fill the gap by:
   (3a) Providing a pointer to Joda dates (at least), or
   (3b) Providing an implementation (from Joda or otherwise).

While considering a commons-time project is a good idea, I am wondering if
dates are not such a basic feature of the language that the feature should
not be in lang?

Gary

-----Original Message-----
From: Stephen Colebourne [mailto:scolebourne@btopenworld.com] 
Sent: Monday, May 19, 2003 01:16
To: Jakarta Commons Developers List
Subject: Re: [lang].time.* Was: [VOTE] Release of Commons Lang 2.0

From: "Henri Yandell" <bayard@generationjava.com>
> 1) Should lang contain time related code?
Yes, so long as it doesn't become a rewrite of time classes, thats
http://www.joda.org

> 2) Is there anything in lang.time which should not go in Lang 2.0?

StopWatch - complete
FastDateFormat - probably OK, needs final checking
CalendarUtils - needs a little work to tidy it up. Probably should be called
DateUtils and merged with any useful parts of DateUtils
DateUtils - needs much work, merge useful parts with CalendarUtils

I would like to try to get this in 2.0. It should delay us by a week
perhaps?

The vote (which will need to be stopped and started again later) should
specify the exclusion of the reflect subpackage. In fact we may want to move
it into the sandbox, maybe under [reflect].

Stephen

>
> 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.
>
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message