Java Calendar/Date Issue while adding Month

Question

If we add 1 month in current date(Fri May 31 18:33:00 IST 2013) it yields:

Sun Jun 30 18:33:00 IST 2013

If we subtract 1 month it yields:

Thu May 30 18:33:00 IST 2013

Is it a bug OR can anyone provide the reasoning?

Please find the code for same:

Calendar c1 = Calendar.getInstance()
System.out.println(c1.getTime());
c1.add(Calendar.MONTH, 1);
System.out.println(c1.getTime());
c1.add(Calendar.MONTH, -1);
System.out.println(c1.getTime());

Output

Fri May 31 18:33:00 IST 2013
Sun Jun 30 18:33:00 IST 2013
Thu May 30 18:33:00 IST 2013

Answer 1

The changing of the day of month is the expected behaviour, documented here, as "Add rule 2": http://docs.oracle.com/javase/6/docs/api/java/util/Calendar.html

add(f, delta) adds delta to field f. This is equivalent to calling set(f, get(f) + delta) with two adjustments:

Add rule 1. The value of field f after the call minus the value of field f before the call is delta, modulo any overflow that has occurred in field f. Overflow occurs when a field value exceeds its range and, as a result, the next larger field is incremented or decremented and the field value is adjusted back into its range.

Add rule 2. If a smaller field is expected to be invariant, but it is impossible for it to be equal to its prior value because of changes in its minimum or maximum after field f is changed or other constraints, such as time zone offset changes, then its value is adjusted to be as close as possible to its expected value. A smaller field represents a smaller unit of time. HOUR is a smaller field than DAY_OF_MONTH. No adjustment is made to smaller fields that are not expected to be invariant. The calendar system determines what fields are expected to be invariant.

With these rules in place, there's no way to keep the day of month if you add 1 month, followed by adding -1 months.

Answer 2

No, it's a feature and is documented (sorry being picky here, but did you actually read the docs before asking?). Read the Field Manipulation sectione in the docs about the add() method. Relevant part:

If a smaller field is expected to be invariant, but it is impossible for it to be equal to its prior value because of changes in its minimum or maximum after field f is changed or other constraints, such as time zone offset changes, then its value is adjusted to be as close as possible to its expected value.

Example: Consider a GregorianCalendar originally set to August 31, 1999. Calling add(Calendar.MONTH, 13) sets the calendar to September 30, 2000. Add rule 1 sets the MONTH field to September, since adding 13 months to August gives September of the next year. Since DAY_OF_MONTH cannot be 31 in September in a GregorianCalendar, add rule 2 sets the DAY_OF_MONTH to 30, the closest possible value. Although it is a smaller field, DAY_OF_WEEK is not adjusted by rule 2, since it is expected to change when the month changes in a GregorianCalendar.

Answer 3

This is correct as it is designed.

When you add one month from May 31st you get June 30th (the last day of the month).

When you subtract one month from June 30th you get May 31st (one month earlier).

The calculation are done when you get the time with getTime(). Therefore I don't see any bug here.

Answer 4

Update for the modern age, using the java.time classes that supplant the troublesome old legacy date-time classes including Calendar.

Time zone

Define your time zone. Specify a proper time zone name in the format of continent/region, such as America/Montreal, Africa/Casablanca, or Pacific/Auckland. Never use the 3-4 letter abbreviation such as EST or IST as they are not true time zones, not standardized, and not even unique(!). I am guessing you meant India time by IST, but perhaps Irish Standard Time or other?

final ZoneId z = ZoneId.of ( "Asia/Kolkata" );

The ZonedDateTime class represents a moment on the timeline adjusted into a particular time zone.

final ZonedDateTime zdt = ZonedDateTime.of ( 2013, 5, 31, 18, 33, 0, 0, z );

plusMonths | minusMonths

final ZonedDateTime zdtMonthPlus = zdt.plusMonths ( 1 );
final ZonedDateTime zdtMonthMinus = zdtMonthPlus.minusMonths ( 1 );

Dump to console.

System.out.println ( "zdt.toString(): " + zdt );
System.out.println ( "zdtMonthPlus.toString(): " + zdtMonthPlus );
System.out.println ( "zdtMonthMinus.toString(): " + zdtMonthMinus );

We see the same behavior as with the legacy Calendar class. When adding a month from May 31 there is no June 31st so it falls back to the last day of the month, June 30. When subtracting from June 30, the class tries to match the same day-of-month, so it uses May 30.

zdt.toString(): 2013-05-31T18:33+05:30[Asia/Kolkata]

zdtMonthPlus.toString(): 2013-06-30T18:33+05:30[Asia/Kolkata]

zdtMonthMinus.toString(): 2013-05-30T18:33+05:30[Asia/Kolkata]

plus( Duration) | minus( Duration )

If you want another behavior, use another approach to your code. For example, if by "month" you really mean “30 days of generic 24-hour days (ignoring anomalies such as Daylight Saving Time)”, then add/subtract durations of 30 days.

Duration thirtyDays = Duration.ofDays( 30 );  // 30 days of generic 24-hour length. Ignoring anomalies such as DST. Ignoring calendar months.
final ZonedDateTime zdtMonthPlusDuration = zdt.plus ( thirtyDays );
final ZonedDateTime zdtMonthMinusDuration = zdtMonthPlusDuration.minus ( thirtyDays );

thirtyDays.toString(): PT720H

zdtMonthPlusDuration.toString(): 2013-06-30T18:33+05:30[Asia/Kolkata]

zdtMonthMinusDuration.toString(): 2013-05-31T18:33+05:30[Asia/Kolkata]

---

About java.time

The java.time framework is built into Java 8 and later. These classes supplant the troublesome old legacy date-time classes such as java.util.Date, Calendar, & SimpleDateFormat.

The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.

To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations. Specification is JSR 310.

Where to obtain the java.time classes?

• Java SE 8 and SE 9 and later
  • Built-in.
  • Part of the standard Java API with a bundled implementation.
  • Java 9 adds some minor features and fixes.
• Java SE 6 and SE 7
  • Much of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
• Android
  • The ThreeTenABP project adapts ThreeTen-Backport (mentioned above) for Android specifically.
  • See How to use ThreeTenABP….

The ThreeTen-Extra project extends java.time with additional classes. This project is a proving ground for possible future additions to java.time. You may find some useful classes here such as Interval, YearWeek, YearQuarter, and more.