commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Yandell <>
Subject RE: lang.time.* Was: [VOTE] Release of Commons Lang 2.0
Date Sun, 18 May 2003 23:51:40 GMT

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,, 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


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 []
> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message