Re: [lang].time.* Was: [VOTE] Release of Commons Lang 2.0

[Stephen Colebourne <sc...@btopenworld.com>]

From: "Henri Yandell" <ba...@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

Re: [lang].time.* - almost at 2.0...

[Stephen Colebourne <sc...@btopenworld.com>]

I have tidied up the time package as follows:

StopWatch - duration formatter moved to DurationFormatUtils
FastDateFormat - additional JDK1.4 pattern letter added (plus extra one for
ISO)
DateUtils split to DateFormatUtils and DurationFormatUtils
CalendarUtils renamed to DateUtils


DurationFormatUtils is package scoped ATM, as it needs more work. You need
to be able to control which fields get output.
DateUtils (previously CalendarUtils) has not been checked for releasability
yet.

I am away for a few days if anyone wants to look at CalendarUtils and check
it over...then we should be clear for 2.0.

Stephen

----- Original Message -----
From: "Stephen Colebourne" <sc...@btopenworld.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Monday, May 19, 2003 9:15 AM
Subject: Re: [lang].time.* Was: [VOTE] Release of Commons Lang 2.0


> From: "Henri Yandell" <ba...@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
>


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