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>