(cal) RFE: Replace Calendar and GregorianCalendar
No Resource Available,
request for enhancement
The design of java.util.Calendar is deeply flawed. The class combines two separate representations of time (a simple linear time stamp as well as a calendar-based multi-field representation) with the mapping algorithms between these two representations. The two representations are not continuously kept in sync, but only resynched as a side effect of several method calls, including some where this is rather unexpected (see bug 4340146).
The class should be replaced with two separate classes/interfaces that encapsulate either state or mapping. CalendarDate would encapsulate a calendar-dependent representation of a point in time using multiple fields - similar to the fields of the current Calendar class. CalendarSystem (since the better name Calendar has been taken) encapsulates a mapping between Date and CalendarDate, including methods that manipulate a CalendarDate in calendar-specific ways (say, adding a month).
Taking the current Calendar class, public/protected members could go to the two new classes/interfaces as follows:
CalendarDate: all constants, clear, clone, equals, get, hashCode, set, toString
CalendarSystem: mapToCalendarDate (replaces computeFields, setTime, setTimeInMillis), mapFromCalendarDate (replaces computeTime, getTime, getTimeInMillis), add, clone, equals, getActualMaximum, getActualMinimum, getAvailableLocales, getFirstDayOfWeek, getGreatestMaximum, getGreatestMinimum, getInstance, getLeastMaximum, getMaximum, getMinimalDaysInFirstWeek, getMinimum, getTimeZone (?), hashCode, isLenient, roll, setFirstDayOfWeek, setLenient, setMinimalDaysInFirstWeek, setTimeZone, toString
neither: areFieldsSet, "fields" field, isSet, isTimeSet, time, after, before, complete, computeFields, computeTime, getTime, getTimeInMillis, internalGet, isSet
It might be possible to define CalendarSystem is an interface, and then reimplement Calendar as "extends CalendarDate implements CalendarSystem".
Calendar and GregorianCalendar should be deprecated. All methods referring to them should either be deprecated or be changed to refer to CalendarDate or CalendarSystem.
It's not clear whether a public replacement for GregorianCalendar is needed. Applications should never rely on a specific calendar, but a public class may be useful for pluggable locales.
CR description from 6193609:
I would like to nominate Joda Time (found here: http://joda-time.sourceforge.net/userguide.html) for review by Sun. It seems to provide a rich and extensive replacement for Date and Calendar and replacing those two is certainly well-warranted.
This has been discussed in this discussion forum: http://forums.java.net/jive/thread.jspa?threadID=198&tstart=0
Posted Date : 2005-10-05 01:17:08.0
A new calendar API has been rejected by the Tiger steering commitee. So, this RFE will not be fixed.
We will revisit this RFE for Dolphin.
Posted Date : 2005-10-05 01:09:57.0
Submitted On 23-JUL-2000
Create a new package please!
"CalendarSystem" and "CalendarDate" would be very welcome
fix. But why not putting them in their own package? This
way, it would be possible to rename "CalendarSystem"
as "Calendar". The "java.time" package should contains:
1) Date (a super class of java.util.Date without all the
deprecated methods as "getMonth()", "getHour()", etc.)
2) CalendarDate, as descripted in the bug report.
3) Calendar (the renamed "CalendarSystem" from the bug
4) GregorianCalendar (it way be usefull to have public
access to it, since a lot of legacy data are saved with a
very specific calendar).
5) Maybe a "Time" object, as a super class
of "Date". "Date" refer to a time ellapsed since January 1,
1970. "Time" would refer to a time elapsed since any date
(not just January 1).
Submitted On 27-MAR-2001
Please do put the new Calendar make-over into the java.time package as address by MartDesruisseaux.
Submitted On 27-MAR-2001
A long argument version of setTime/getTime with public
access would be very useful along with the Date versions.
Submitted On 15-NOV-2001
If a new set of classes (hopefully in a new package) is
created, it may be worh to consider making an immutable
Date class (e.g. java.time.Date; no change to the current
java.util.Date). A immutable Date would remove the need to
clone the Date in method arguments or return values.
Submitted On 27-JAN-2002
I agree wholeheartedly with the need to look at dates, and
a new package is probably the way to go. However I desire
a 'proper' Java centric design making full use of
See www.joda.org for a downloadable javadoc of this
Interfaces would be defined for:
-ReadableInstant, WritableInstant (millis from 1970)
-ReadableTime, WritableTime (hour,min,sec)
-ReadableDateTime and WritableDateTime (extends the Date
and Time interfaces)
Classes would be defined for
-CalendarSystem (implements WriteableDateTime and supplies
standard ISO/Gregorian implementation)
-DateTime (immutable class implementing ReadableDateTime
and holding a long millis value)
(Note that Writeable extends Readable).
(Note also that there should be Readable and Writable
String and Number interfaces)
These interfaces are defined to work with dates as
specified by ISO8601 between 1583 and 9999, and as per
GregorianCalendar outside these years. The ISO standard
fixes the first day of week (Monday) and first week of year
(the week that 4th Jan is in). Thus the interfaces are
consistent are well defined.
So why use Gregorian methods on the interface when that may
not be appropriate for a different calendar system? Because
that is what 99% of the use of Dates is for. The Calendar
classes failed because they were over-localized, forcing
everybody to use non-intuitive methods when only a tiny
proportion of Java users needed something different. Please
don't make the same mistake again!
An immutable class DateTime implements ReadableDateTime.
This represents milliseconds since 1970 independent of
calendar, and is the key underlying object in the package.
Internationalization is treated separately. Any point in
time can be expressed as a DateTime, except far in the
future or far in the past. The internationalized calendars
would extend CalendarSystem which implements
WritableDateTime. The subclass implementation allows the
specialised locale specific behaviour, but they must also
support the ISO/Gregorian methods. An object of any
calendar system can thus be manipulated by code which only
wishes to work using ISO/Gregorian style methods.
Issues to do with first day of week, first week of year and
daylight savings differing by locale become formatting
issues dealt with by an enhanced TimeZone class. This keeps
the main interface simple, clean and consistent.
Method in other parts of Java and application thus either:
-take in ReadableDateTime (an interface) and return
ImmutableDateTime (a class which implements
-or take in a WritableDateTime (an interface), update it
and return void.
99% of Java use will involve Gregorian-style dates
The ISO8601 standard covers those uses
Interfaces are absolutely vital
Months must be 1 based, not 0 based
See www.joda.org for the proposal in JavaDoc form
Submitted On 28-FEB-2002
Suggestion for new classes: make it possible to specify the
*granularity* of comparisons (equals, compareTo, ...).
Sometimes times have to compared on the second level;
sometimes only minutes (train arrivals); sometimes only
Dates are mostly compared with day granularity (horrible to
do with the current Calendar class); but sometimes week is
the correct granularity (pop charts come to mind).
Submitted On 17-JUN-2002
The Joda Time project at
is building a replacement for Date and Calendar. The
javadoc is at
Already built is a comparator implementation controlled by
granularity as suggested above (thanks for the idea!).
Request to Sun: Is this still commit for tiger? If so how
can the Joda project provide input? Where is the JSR?
Submitted On 05-AUG-2002
Why the new Calendar API has been rejected? We would
appreciate more hints in the evaluation comment.
Submitted On 06-AUG-2002
I too would be interested in more info. Is this lack of time in
the schedule? There is a clear need here. Should we resubmit
this for Java 1.6?
Also, was the open source Joda project considered - after all
it could supply most of the code...
Submitted On 29-AUG-2002
This is ridiculous, there is a long bug-trail related to
SimpleDateFormat not being thread-safe that dates back to
1996. With the bug being raised by users who have problems
and then being closed by SUN who refuse to fix it, and then
being raised again because it causes real inconvenience.
The previous bug report 4146524 was closed in 2001 with the
comment that the whole problem would be solved by the new
Calendar handling proposed here - now a year later this is
shot dead. Great.
This wastes lots of peoples time and makes date handling
generally much more ugly than it should be. By refusing to fix
it the problem is not going away, its just annoying everyone.
Submitted On 29-AUG-2002
Shocking, after promising to fix 4228335 by implementing this
one instead, you simply wait 2 years and then reject it.
Implementing threadsafe formatting classes is essential to
many web implementations. We attempt to 'new' as few
objects as possible to get good performance only to be forced
to either single thread or create lots of objects.
Has anyone written their own implementation? Maybe that is
the only way to make some reasonable progress here.
Submitted On 03-SEP-2002
I have been struggling with the problem indicated here for a
long time. It seems there is no hope to get this fixed in the
short period of time. I have tried many different workaround,
(from bug 4228335). No matter what I do, I just can't make it
work. I may look at the open source project mentioned here.
It is understadable Sun is reluctant to fix it, there are too
many things involved.
What bothers me the most is the lack of information. To most
developers, they won't know this hidden, nasty problem until
they encounter it by themselves. The classes happen to be
very common, get most used daily. If you are writing
something VB like, it might be OK. But when the code is
required to run for a long time, you get hit by it, and it is very
hard to reproduce. In my case, it often happen after more
than 10 days running. You apply the fix, then after another
long period of time, BOOM!
My quest to Sun: no fix is fine. But please try to make
developers know the problem.
Submitted On 12-APR-2003
We can re-look into this area.
Submitted On 28-JAN-2005
how's re-looking going?
Submitted On 22-FEB-2005
The replacement has been released.
PLEASE NOTE: JDK6 is formerly known as Project Mustang