You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Charles Burdick <ch...@yahoo.com> on 2002/12/19 20:32:49 UTC

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*.

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>


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>