What's the difference between adding DAY_OF_MONTH or DAY_OF_YEAR to a Calendar object?

I want to increase a certain date by 1 day. I create a Calendar object like:

Calendar cal = Calendar.getInstance();
cal.set(Calendar.YEAR, 2012);
cal.set(Calendar.MONTH, 0);
cal.set(Calendar.DAY_OF_MONTH, 31);

Then, for increasing it by 1 day, I can do 2 things :

cal.add(Calendar.DAY_OF_MONTH, 1);

OR

cal.add(Calendar.DAY_OF_YEAR, 1);

There are also other "DAY" constants, but I get the same result using the above 2 methods of increasing the day by 1. In which case will I get different results for the two?

For adding it really makes no difference, but this

Calendar c = Calendar.getInstance();
System.out.println(c.get(Calendar.DAY_OF_MONTH));
System.out.println(c.get(Calendar.DAY_OF_YEAR));

prints

28
363

> Calendar.add Adds or subtracts the specified amount of time to the given calendar field, based on the calendar's rules.

Here you have a list of the fields of Calendar that you can add or subtract:

• MILLISECOND is the number of milliseconds between 0 and 999

• SECOND is the number of seconds between 0 and 59

• MINUTE is the number of minutes between 0 and 59

• HOUR is the number of hours between 0 and 11

• HOUR_OF_DAY is the number of hours between 0 and 23

• DAY_OF_WEEK is the day in relation of the week between 1 and 7

• DAY_OF_MONTH is the day in relation of the month between 1 and 31

• DAY_OF_YEAR is the day in relation of the year between 1 and 366

• WEEK_OF_MONTH is the week in relation of the month starting from 1

• WEEK_OF_YEAR is the week in relation of the year starting from 1

• MONTH is the month in relation of the year between 0 and 11

• YEAR is the number of years starting from 1

Hours, days and weeks have multiple fields but it doesn't matter which one you choose¹. For example using -8 for DAY_OF_WEEK will work.

calendar.add(Calendar.DAY_OF_MONTH, -2); // subtract 2 days
calendar.add(Calendar.DAY_OF_WEEK, -2);  // subtract 2 days
calendar.add(Calendar.DAY_OF_YEAR, -2);  // subtract 2 days

calendar.add(Calendar.YEAR, -2);         // subtract 2 years

---

¹_{It doesn't matter only using Calendar.add, with other operations the results might be different.}

Use Calendar.DATE for your purposes. In your case these three constants are synonyms.

It doesn't make any difference when you call add. However the getters return different results :D

code snippet from GregorianCalendar#add

case DAY_OF_MONTH: // synonym of DATE
 case DAY_OF_YEAR:
 case DAY_OF_WEEK:
    break;

DAY_OF_YEAR

Field number for get and set indicating the day number within the current year

DAY_OF_MONTH

Field number for get and set indicating the day of the month. This is a synonym for DATE

You will see difference if the day is greater than 31.

You essentially advance the date by one, in both the cases. So there is no difference in both the approaches.

But sticking to a single method will render consistency across your codebase, maintainers will feel at home and probably the runtime optimizes the method call by compiling it as well.

Actually, there can and will be a difference depending on what field type you choose:

> * > http://docs.oracle.com/javase/1.5.0/docs/api/java/util/Calendar.html > > Usage model. > > To motivate the behavior of add() and roll(), consider a > user interface component with increment and decrement buttons for the > month, day, and year, and an underlying GregorianCalendar. If the > interface reads January 31, 1999 and the user presses the month > increment button, what should it read? If the underlying > implementation uses set(), it might read March 3, 1999. A better > result would be February 28, 1999. Furthermore, if the user presses > the month increment button again, it should read March 31, 1999, not > March 28, 1999. By saving the original date and using either add() or > roll(), depending on whether larger fields should be affected, the > user interface can behave as most users will intuitively expect.

tl;dr

LocalDate.of( 2012 , Month.JANUARY , 31 )
    .plusDays( 1 )

>2012-02-01

…or…

LocalDate.of( 2012 , 1 , 31 )  // Sane numbering: 1-12 for January-December, and `2012` means year 2012.
    .plusDays( 1 )

>2012-02-01

java.time

The Calendar class is confusing, awkward, and poorly designed. Among its many problems are these pass-the-units-flag methods. Fortunately, you can now forget all about this class.

The java.time classes built into Java 8 and later now supplant the legacy date-time classes.

LocalDate

The LocalDate class represents a date-only value without time-of-day and without time zone.

A time zone is crucial in determining a date. For any given moment, the date varies around the globe by zone. For example, a few minutes after midnight in Paris France is a new day while still “yesterday” in Montréal Québec.

If no time zone is specified, the JVM implicitly applies its current default time zone. That default may change at any moment, so your results may vary. Better to specify your desired/expected time zone explicitly as an argument.

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(!).

ZoneId z = ZoneId.of( "America/Montreal" ) ;  
LocalDate today = LocalDate.now( z ) ;

If you want to use the JVM’s current default time zone, ask for it and pass as an argument. If omitted, the JVM’s current default is applied implicitly. Better to be explicit, as the default may be changed at any moment during runtime by any code in any thread of any app within the JVM.

ZoneId z = ZoneId.systemDefault() ;  // Get JVM’s current default time zone.

Or specify a date. You may set the month by a number, with sane numbering 1-12 for January-December.

LocalDate ld = LocalDate.of( 1986 , 2 , 23 ) ;  // Years use sane direct numbering (1986 means year 1986). Months use sane numbering, 1-12 for January-December.

Or, better, use the Month enum objects pre-defined, one for each month of the year. Tip: Use these Month objects throughout your codebase rather than a mere integer number to make your code more self-documenting, ensure valid values, and provide type-safety.

LocalDate ld = LocalDate.of( 1986 , Month.FEBRUARY , 23 ) ;

Parts

With a LocalDate in hand, you may interrogate for its parts.

To get the day-of-month, that is, the "date" such as 23 from January 23, 2018:

int dayOfMonth = ld.getDayOfMonth() ; // 1-31, depending on length of month.

To get the nth day of the year, from 1-365, or in a leap year, 1-366:

int dayOfYear = ld.getDayOfYear() ;

Math

Adding or subtracting days is quite simple and intuitive in java.time. Convenience methods and span-of-time objects make the code much more clear.

LocalDate dayLater = ld.plusDays( 1 ) ;

So getting tomorrow would be:

LocalDate tomorrow = LocalDate.now( ZoneId.of( "Africa/Tunis" ) ).plusDays( 1 ) ;

Alternatively, you can represent a span-of-time unattached to the timeline. For years-months-days, use Period. For hours-minutes-seconds, use Duration.

Period p = Period.ofDays( 1 ) ;
LocalDate dayLater = ld.plus( p ) ;

Note that java.time uses sane numbering, unlike the legacy classes. The number 2018 is the year 2018. Months are numbered 1-12 for January-December. Days of the week are numbered 1-7 for Monday-Sunday, per the ISO 8601 standard.

---

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, Java 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 Java SE 7
• Much of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
• Android
• Later versions of Android bundle implementations of the java.time classes.
• For earlier Android, the ThreeTenABP project adapts ThreeTen-Backport (mentioned above). 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.

In addition of date it does not make any difference whether you use DAY_OF_MONTH or DAY_OF_YEAR. However, it makes sense when you get call getter and pass one of those.

Use DATE or DAY_OF_MONTH both are same

Here is the difference :

DATE or DAY_OF_MONTH : Get and Set indicating the day of the month
DAY_OF_WEEK          : get and set indicating the week number within the current month
DAY_OF_YEAR          : get and set indicating the day number within the current ye

Source : https://docs.oracle.com/javase/7/docs/api/java/util/Calendar.html

   public static String findDay(int month, int day, int year) {
// Creating a calendar
  Calendar calndr = Calendar.getInstance();
     calndr.set(Calendar.MONTH, month-1);
     calndr.set(Calendar.YEAR, year);        
     calndr.set(Calendar.DAY_OF_MONTH, day);
     String[] strDays = new String[] { "Sunday", "Monday", "Tuesday", "Wednesday", "Thursday",
                "Friday", "Saturday" };
      return strDays[calndr.get(Calendar.DAY_OF_WEEK)-1].toUpperCase();
    }

}