commons-dev mailing list archives

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

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

Currently lang.time is made up of 4 classes, all from different

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?


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

View raw message