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

Question

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(Cal         


        

Answer 1

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

Answer 2

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.

Answer 3

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;

Answer 4

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