commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <>
Subject Re: [lang] status of CalendarUtils proposal
Date Sun, 08 Sep 2002 19:11:02 GMT
I believe that Sun would explain it as:

Date is locale independent (milliseconds only)
Calendar is locale/calendar specific

Of course Date has calendar specific methods, but they are all deprecated.
C'est la vie.


PS. I have an interest in this from my Joda project where we are building a
complete replacement for dates in Java.

----- Original Message -----
From: "Serge Knystautas" <>
> From: "Steven Caswell" <>
> > I'm in a quandry over how to do a separate DateUtils.  I've got a couple
> > of things that would go into it that are stricly Date-related. What I'm
> > not clear on is whether stuff already in CalendarUtils should move into
> > DateUtils.  For example, there is a Date version of truncate and a
> > Calendar version of truncate. They do the same thing but with different
> > types as input. Should the Date version of truncate move to DateUtils?
> > Does it make sense to separate the different versions of the same
> > operation based solely on parameter/return type? Does that complicate or
> > simplify the API?
> What kind of functions did you have in mind that were strictly Date only?
> don't really think of them as that different, so was curious as to what
> would have in one but not the other?  I wrote that CalendarUtils to accept
> Date in any parameter that takes a Calendar because it's easy to go from
> Calendar -> Date (with the getTime() method), but Date -> Calendar is
> harder.
> Serge Knystautas
> Loki Technologies
> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message