You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Sean Schofield <ne...@schof.com> on 2002/12/18 20:29:39 UTC
[lang] DateUtils package organization
Can we review what classes we have now and what packages they belong in.
By my count we have DateUtils (which may be renamed to DateFormatUtils),
CalendarUtils and FastDateFormat.
As for the packages I think we have discussed
'org.apache.commons.lang.time' any others? What
about 'org.apache.commons.lang.date'? Are we agreed that we should move
to a new subpackage at this point with 3 classes?
- sean
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] DateUtils package organization
Posted by Sean Schofield <ne...@schof.com>.
Henri Yandell wrote:
>On Wed, 18 Dec 2002, Sean Schofield wrote:
>
>
>
>>Can we review what classes we have now and what packages they belong in.
>>
>>By my count we have DateUtils (which may be renamed to DateFormatUtils),
>>CalendarUtils and FastDateFormat.
>>
>>
>
>Matches my list.
>
>
>
>>As for the packages I think we have discussed
>>'org.apache.commons.lang.time' any others?
>>
>>
>
>
>
>>What about 'org.apache.commons.lang.date'?
>>
>>
>
>For me, time wins over date as it more correctly addresses the real scope.
>'Date' was always a misnamed class for 'InstantInTime' and we'd not want
>to limit ourselves to the real 'Date' things.
>
>
>
>>Are we agreed that we should move
>>to a new subpackage at this point with 3 classes?
>>
>>
>
>It seems to be leaning that way. I'm +1 on it.
>
>Hen
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
+1 for me then as well. ("time" is ok but lets leave DateUtils
classname alone for now)
Do others have thoughts/votes on this?
- sean
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] DateUtils package organization
Posted by Henri Yandell <ba...@generationjava.com>.
On Wed, 18 Dec 2002, Sean Schofield wrote:
> Can we review what classes we have now and what packages they belong in.
>
> By my count we have DateUtils (which may be renamed to DateFormatUtils),
> CalendarUtils and FastDateFormat.
Matches my list.
> As for the packages I think we have discussed
> 'org.apache.commons.lang.time' any others?
> What about 'org.apache.commons.lang.date'?
For me, time wins over date as it more correctly addresses the real scope.
'Date' was always a misnamed class for 'InstantInTime' and we'd not want
to limit ourselves to the real 'Date' things.
> Are we agreed that we should move
> to a new subpackage at this point with 3 classes?
It seems to be leaning that way. I'm +1 on it.
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Date/Time should not be in [lang]
Posted by "Sean C. Sullivan" <se...@seansullivan.com>.
I agree with Charles Burdick.
Let's keep [lang] as small as possible.
IMHO, I don't think [lang] benefits from any date and time
util classes.
>-- Original Message --
>From: Charles Burdick
>Subject: Date/Time should not be in [lang]
>
>I haven't read the various Date/Time threads completely. (Cuz there's
>over 50 in just the last few days!)
>
>But to me, putting these "Utils" into [lang] is a *bad idea*.
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Date/Time should not be in [lang]
Posted by Charles Burdick <ch...@yahoo.com>.
I haven't read the various Date/Time threads completely. (Cuz there's
over 50 in just the last few days!)
But to me, putting these "Utils" into [lang] is a *bad idea*.
This is the perfect opportunity to utilize the Commons charter with its
focus on well-defined common components. Everyone agrees it would be
great to have a new implementation of Calendar and DateFormat that's
not on crack like Sun's.
However, I don't see any correlation with the rest of [lang]. Where is
the common use and common change that involves the rest of [lang]? How
would these date/time items depend on other parts of [lang]?
I always thought it was weird and problematic that Sun slapped Date and
Calendar in [util] but DateFormat was in [text]. To me, if Commons
packages date/time objects in [lang], we're just repeating bad
practices.
I'd much rather have an independent [DATE] or [TIME] or [DATETIME]
package. Simple, clearly defined. If you need to use 'em, you import
JAR, if you don't, you don't.
Thanks,
Chuck
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>