Develop Reference

LocalTime.MIDNIGHT vs. LocalTime.MIN - is there any difference?

I recently answered some questions using LocalDate.atStartOfDay() and LocalDate.atTime(LocalTime.MIN).
I was wondering why there is no LocalDate.atEndOfDay() or similar, so one has to use LocalDate.atTime(LocalTime.MAX) in order to get the very last moment (in nanos, I think) of that specific day.
I had a look at the source of LocalDate and LocalTime and got slightly confused by this:
/**
* Combines this date with the time of midnight to create a {#code LocalDateTime}
* at the start of this date.
* <p>
* This returns a {#code LocalDateTime} formed from this date at the time of
* midnight, 00:00, at the start of this date.
*
* #return the local date-time of midnight at the start of this date, not null
*/
public LocalDateTime atStartOfDay() {
return LocalDateTime.of(this, LocalTime.MIDNIGHT);
}
Contrary to my expectation, this method returns a LocalDateTime using LocalTime.MIDNIGHT instead of LocalTime.MIN.
Of course, I opened the OpenJDK source of LocalTime and was sure to find out the difference myself, but I found out there is no difference apart from the name of the constant:
/**
* Constants for the local time of each hour.
*/
private static final LocalTime[] HOURS = new LocalTime[24];
static {
for (int i = 0; i < HOURS.length; i++) {
HOURS[i] = new LocalTime(i, 0, 0, 0);
}
MIDNIGHT = HOURS[0]; // <--- == MIN
NOON = HOURS[12];
MIN = HOURS[0]; // <--- == MIDNIGHT
MAX = new LocalTime(23, 59, 59, 999_999_999);
}
While I totally understand the presence of NOON and MAX, I don't really get why there are MIN and MIDNIGHT when obviously one of them would be enough since they have the very same value.
Can anyone tell me the reason why...
... there are two constants having the very same value and
... why the code uses MIDNIGHT for the start of a day?
Is it just for having something more readable in some situations?
But why isn't MIN used in LocalTime.atStartOfDay() but rather LocalTime.MIDNIGHT?

MIN exists to provide the minimum value, which is consistent with other java.time.* classes.
MIDNIGHT exists to provide semantic meaning to developers, and as a place to indicate to Javadoc readers that midnight is considered to be at the start of the day (not the end).
Summary, the semantic benefits in code reading outweigh the cost of the extra constant.
(Source: I'm the main java.time.* author)

Calcuting the date difference for a specified number of days using LocalDate class

I'm using openjdk version 1.8.0_112-release for development but will need to support previous JDK versions too (pre-Java-8) - so can't use java.time.
I am writing a utitily class to calculate the date to see if a saved date is before the current date which means its expired.
However, I am not sure I have done this the correct way. I am using LocalDate class to calculate the days. The expiration is counted starting from the date and time the user clicked save. That date will be saved and a check will be done against this saved date and time and the current date and time i.e. when the user logs in.
Is this the best way to do it? I would like to keep to the LocalDate class.
import org.threeten.bp.LocalDate;
public final class Utilities {
private Utilities() {}
public static boolean hasDateExpired(int days, LocalDate savedDate, LocalDate currentDate) {
boolean hasExpired = false;
if(savedDate != null && currentDate != null) {
/* has expired if the saved date plus the specified days is still before the current date (today) */
if(savedDate.plusDays(days).isBefore(currentDate)) {
hasExpired = true;
}
}
return hasExpired;
}
}
I'm using the class like this:
private void showDialogToIndicateLicenseHasExpired() {
final LocalDate currentDate = LocalDate.now();
final int DAYS_TO_EXPIRE = 3;
final LocalDate savedDate = user.getSavedDate();
if(hasDateExpired(DAYS_TO_EXPIRE, savedDate, currentDate)) {
/* License has expired, warn the user */
}
}
I am looking a solution that will take in account time zones. If a license was set to expire in 3 days, and the user was to travel to a different time zone. i.e. they could be ahead or behind based on hours. The license should still expire.

Your code is basically fine. I would do it basically the same way, just with a detail or two being different.
As Hugo has already noted, I would use java.time.LocalDate and drop the use of ThreeTen Backport (unless it is a specific requirement that your code can run on Java 6 or 7 too).
Time Zone
You should decide in which time zone you count your days. Also I would prefer if you make the time zone explicit in yout code. If your system will be used in your own time zone only, the choice is easy, just make it explicit. For example:
final LocalDate currentDate = LocalDate.now(ZoneId.of("Asia/Hong_Kong"));
Please fill in the relevant zone ID. This will also make sure the program works correctly even if one day it happens to run on a computer with an incorrect time zone setting. If your system is global, you may want to use UTC, for example:
final LocalDate currentDate = LocalDate.now(ZoneOffset.UTC);
You will want to do similarly when saving the date when the user clicked Save so your data are consistent.
72 hours
Edit: I understand from your comment that you want to measure 3 days, that is, 72 hours, from the save time to determine whether the license has expired. For this a LocalDate does not give you enough information. It is only a date without a clock time, like May 26 2017 AD. There are some other options:
Instant is a point in time (with nanosecond precision, even). This is the simple solution to make sure the expiration happens after 72 hours no matter if the user moves to another time zone.
ZonedDateTime represents both a date and a time and a time zone, like 29 May 2017 AD 19:21:33.783 at offset GMT+08:00[Asia/Hong_Kong]. If you want to remind the user when the saved time was, a ZonedDateTime will you allow you to present that information with the time zone in which the save date was calculated.
Finally OffsetDateTime would work too, but it doesn’t seem to give you much of the advantages of the two others, so I will not eloborate on this option.
Since an instant is the same in all time zones, you don’t specify a time zone when getting the current instant:
final Instant currentDate = Instant.now();
Adding 3 days to an Instant is a little different LocalDate, but the rest of the logic is the same:
public static boolean hasDateExpired(int days, Instant savedDate, Instant currentDate) {
boolean hasExpired = false;
if(savedDate != null && currentDate != null) {
/* has expired if the saved date plus the specified days is still before the current date (today) */
if (savedDate.plus(days, ChronoUnit.DAYS).isBefore(currentDate)) {
hasExpired = true;
}
}
return hasExpired;
}
The use of ZonedDateTime, on the other hand, goes exactly like LocalDate in the code:
final ZonedDateTime currentDate = ZonedDateTime.now(ZoneId.of("Asia/Hong_Kong"));
If you want the current time zone setting from the JVM where the program runs:
final ZonedDateTime currentDate = ZonedDateTime.now(ZoneId.systemDefault());
Now if you declare public static boolean hasDateExpired(int days, ZonedDateTime savedDate, ZonedDateTime currentDate), you may do as before:
/* has expired if the saved date plus the specified days is still before the current date (today) */
if (savedDate.plusDays(days).isBefore(currentDate)) {
hasExpired = true;
}
This will perform the correct comparison even if the two ZonedDateTime objects are in two different time zones. So no matter if the user travels to a different time zone, s/he will not get fewer nor more hours before the license expires.

You can use ChronoUnit.DAYS (in org.threeten.bp.temporal package, or in java.time.temporal if you use java 8 native classes) to calculate the number of days between the 2 LocalDate objects:
if (savedDate != null && currentDate != null) {
if (ChronoUnit.DAYS.between(savedDate, currentDate) > days) {
hasExpired = true;
}
}
Edit (after bounty explanation)
For this test, I'm using threetenbp version 1.3.4
As you want a solution that works even if the user is in a different timezone, you shouldn't use LocalDate, because this class doesn't handle timezone issues.
I think the best solution is to use the Instant class. It represents a single point in time, no matter in what timezone you are (at this moment, everybody in the world are in the same instant, although the local date and time might be different depending on where you are).
Actually Instant is always in UTC Time - a standard indepedent of timezone, so very suitable to your case (as you want a calculation independent of what timezone the user is in).
So both your savedDate and currentDate must be Instant's, and you should calculate the difference between them.
Now, a subtle detail. You want the expiration to happen after 3 days. For the code I did, I'm making the following assumptions:
3 days = 72 hours
1 fraction of a second after 72 hours, it's expired
The second assumption is important for the way I implemented the solution. I'm considering the following cases:
currentDate is less than 72 hours after savedDate - not expired
currentDate is exactly 72 hours after savedDate - not expired (or expired? see comments below)
currentDate is more than 72 hours after savedDate (even by a fraction of a second) - expired
The Instant class has nanosecond precision, so in case 3 I'm considering that it's expired even if it's 1 nanosecond after 72 hours:
import org.threeten.bp.Instant;
import org.threeten.bp.temporal.ChronoUnit;
public static boolean hasDateExpired(int days, Instant savedDate, Instant currentDate) {
boolean hasExpired = false;
if (savedDate != null && currentDate != null) {
// nanoseconds between savedDate and currentDate > number of nanoseconds in the specified number of days
if (ChronoUnit.NANOS.between(savedDate, currentDate) > days * ChronoUnit.DAYS.getDuration().toNanos()) {
hasExpired = true;
}
}
return hasExpired;
}
Note that I used ChronoUnit.DAYS.getDuration().toNanos() to get the number of nanoseconds in a day. It's better to rely on the API instead of having hardcoded big error-prone numbers.
I've made some tests, using dates in the same timezone and in different ones.
I used ZonedDateTime.toInstant() method to convert the dates to Instant:
import org.threeten.bp.ZoneId;
import org.threeten.bp.ZonedDateTime;
// testing in the same timezone
ZoneId sp = ZoneId.of("America/Sao_Paulo");
// savedDate: 22/05/2017 10:00 in Sao Paulo timezone
Instant savedDate = ZonedDateTime.of(2017, 5, 22, 10, 0, 0, 0, sp).toInstant();
// 1 nanosecond before expires (returns false - not expired)
System.out.println(hasDateExpired(3, savedDate, ZonedDateTime.of(2017, 5, 25, 9, 59, 59, 999999999, sp).toInstant()));
// exactly 3 days (72 hours) after saved date (returns false - not expired)
System.out.println(hasDateExpired(3, savedDate, ZonedDateTime.of(2017, 5, 25, 10, 0, 0, 0, sp).toInstant()));
// 1 nanosecond after 3 days (72 hours) (returns true - expired)
System.out.println(hasDateExpired(3, savedDate, ZonedDateTime.of(2017, 5, 25, 10, 0, 0, 1, sp).toInstant()));
// testing in different timezones (savedDate in Sao Paulo, currentDate in London)
ZoneId london = ZoneId.of("Europe/London");
// In 22/05/2017, London will be in summer time, so 10h in Sao Paulo = 14h in London
// 1 nanosecond before expires (returns false - not expired)
System.out.println(hasDateExpired(3, savedDate, ZonedDateTime.of(2017, 5, 25, 13, 59, 59, 999999999, london).toInstant()));
// exactly 3 days (72 hours) after saved date (returns false - not expired)
System.out.println(hasDateExpired(3, savedDate, ZonedDateTime.of(2017, 5, 25, 14, 0, 0, 0, london).toInstant()));
// 1 nanosecond after 3 days (72 hours) (returns true - expired)
System.out.println(hasDateExpired(3, savedDate, ZonedDateTime.of(2017, 5, 25, 14, 0, 0, 1, london).toInstant()));
PS: for case 2 (currentDate is exactly 72 hours after savedDate - not expired) - if you want this to be expired, just change the if above to use >= instead of >:
if (ChronoUnit.NANOS.between(savedDate, currentDate) >= days * ChronoUnit.DAYS.getDuration().toNanos()) {
... // it returns "true" for case 2
}
If you don't want nanosecond precision and just want to compare the days between the dates, you can do as in #Ole V.V's answer. I believe our answers are very similar (and I suspect that the codes are equivalent, although I'm not sure), but I haven't tested enough cases to check if they differ in any particular situation.

The Answer by Hugo and the Answer by Ole V.V. Are both correct, and the one by Ole V.V. is most important, as time zone is crucial to determine the current date.
Period
Another useful class for this work is the Period class. This class represents a span of time unattached to the timeline as a number of years, months, and days.
Note that this class is not appropriate to representing the elapsed time needed for this Question because this representation is "chunked" as years, then months, and then any remaining days. So if LocalDate.between( start , stop ) were used for an amount of several weeks, the result might be something like "two months and three days". Notice that this class does not implement the Comparable interface for this reason, as one pair of months cannot be said to be bigger or smaller than another pair unless we know which specific months are involved.
We can use this class to represent the two-day grace-period mentioned in the Question. Doing so makes our code more self-documenting. Better to pass around an object of this type than passing a mere integer.
Period grace = Period.ofDays( 2 ) ;
LocalDate start = LocalDate.of( 2017 , Month.JANUARY , 23 ).plusDays( grace ) ;
LocalDate stop = LocalDate.of( 2017 , Month.MARCH , 7 ) ;
We use ChronoUnit to calculate elapsed days.
int days = ChronoUnit.DAYS.between( start , stop ) ;
Duration
By the way, the Duration class is similar to Period in that it represents a span of time not attached to the timeline. But Duration represents a total of whole seconds plus a fractional second resolved in nanoseconds. From this you can calculate a number of generic 24-hour days (not date-based days), hours, minutes, seconds, and fractional second. Keep in mind that days are not always 24-hours long; here in the United States they currently may be 23, 24, or 25 hours long because of Daylight Saving Time.
This Question is about date-based days, not lumps of 24-hours. So the Duration class is not appropriate here.
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
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.

I think much better to use this:
Duration.between(currentDate.atStartOfDay(), savedDate.atStartOfDay()).toDays() > days;
Duration class placed in java.time package.

As this question is not getting "enough responses", I have added another answer:
I have used "SimpleDateFormat.setTimeZone(TimeZone.getTimeZone("UTC"));" to set the timezone to UTC. So there is no longer a timezone (all Date / time will be set to UTC).
savedDate is set to UTC.
dateTimeNow is also set to UTC, with the number of expired "days" (negative number) added to dateTimeNow.
A new Date expiresDate uses the long milliseconds from dateTimeNow
Check if savedDate.before(expiresDate)
package com.chocksaway;
import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.Calendar;
import java.util.Date;
import java.util.TimeZone;
public class ExpiredDate {
private static final long DAY_IN_MS = 1000 * 60 * 60 * 24;
private static boolean hasDateExpired(int days, java.util.Date savedDate) throws ParseException {
SimpleDateFormat dateFormatUtc = new SimpleDateFormat("yyyy-MMM-dd HH:mm:ss");
dateFormatUtc.setTimeZone(TimeZone.getTimeZone("UTC"));
// Local Date / time zone
SimpleDateFormat dateFormatLocal = new SimpleDateFormat("yyyy-MMM-dd HH:mm:ss");
// Date / time in UTC
savedDate = dateFormatLocal.parse( dateFormatUtc.format(savedDate));
Date dateTimeNow = dateFormatLocal.parse( dateFormatUtc.format(new Date()));
long expires = dateTimeNow.getTime() + (DAY_IN_MS * days);
Date expiresDate = new Date(expires);
System.out.println("savedDate \t\t" + savedDate + "\nexpiresDate \t" + expiresDate);
return savedDate.before(expiresDate);
}
public static void main(String[] args) throws ParseException {
Calendar cal = Calendar.getInstance();
cal.add(Calendar.DATE, 0);
if (ExpiredDate.hasDateExpired(-2, cal.getTime())) {
System.out.println("expired");
} else {
System.out.println("not expired");
}
System.out.print("\n");
cal.add(Calendar.DATE, -3);
if (ExpiredDate.hasDateExpired(-2, cal.getTime())) {
System.out.println("expired");
} else {
System.out.println("not expired");
}
}
}
Running this code gives the following output:
savedDate Mon Jun 05 15:03:24 BST 2017
expiresDate Sat Jun 03 15:03:24 BST 2017
not expired
savedDate Fri Jun 02 15:03:24 BST 2017
expiresDate Sat Jun 03 15:03:24 BST 2017
expired
All dates / times are UTC. First is not expired. Second is expired (savedDate is before expiresDate).

KISS
public static boolean hasDateExpired(int days, java.util.Date savedDate) {
long expires = savedDate().getTime() + (86_400_000L * days);
return System.currentTimeMillis() > expires;
}
Works on old JRE's just fine. Date.getTime() gives milliseconds UTC, so timezone isn't even a factor. The magic 86'400'000 is the number of milliseconds in a day.
Instead of using java.util.Date you can simplify this further if you just use a long for savedTime.

I have built a simple utility class ExpiredDate, with a TimeZone (such as CET), expiredDate, expireDays, and differenceInHoursMillis.
I use java.util.Date, and Date.before(expiredDate):
To see if Date() multiplied by expiryDays plus (timezone difference multiplied by expiryDays) is before expiredDate.
Any date older than the expiredDate is "expired".
A new Date is created by adding (i) + (ii):
(i). I use the number of milliseconds in a day to (DAY_IN_MS = 1000 * 60 * 60 * 24) which is multiplied with the (number of) expireDays.
+
(ii). To deal with a different TimeZone, I find the number of milliseconds between the Default timezone (for me BST), and the TimeZone (for example CET) passed into ExpiredDate. For CET, the difference is one hour, which is 3600000 milliseconds. This is multiplied by the (number of) expireDays.
The new Date is returned from parseDate().
If the new Date is before the expiredDate -> set expired to True.
dateTimeWithExpire.before(expiredDate);
I have created 3 tests:
Set the expiry date 7 days, and expireDays = 3
Not expired (7 days is greater than 3 days)
Set the expiry date / time, and expireDays to 2 days
Not expired - because the CET timezone adds two hours (one hour per day) to the dateTimeWithExpire
Set the expiry date 1 days, and expireDays = 2 (1 day is less than 2 days)
expired is true
package com.chocksaway;
import java.text.ParseException;
import java.util.Calendar;
import java.util.Date;
import java.util.TimeZone;
public class ExpiredDate {
/**
* milliseconds in a day
*/
private static final long DAY_IN_MS = 1000 * 60 * 60 * 24;
private String timeZone;
private Date expiredDate;
private int expireDays;
private int differenceInHoursMillis;
/**
*
* #param timeZone - valid timezone
* #param expiredDate - the fixed date for expiry
* #param expireDays - the number of days to expire
*/
private ExpiredDate(String timeZone, Date expiredDate, int expireDays) {
this.expiredDate = expiredDate;
this.expireDays = expireDays;
this.timeZone = timeZone;
long currentTime = System.currentTimeMillis();
int zoneOffset = TimeZone.getTimeZone(timeZone).getOffset(currentTime);
int defaultOffset = TimeZone.getDefault().getOffset(currentTime);
/**
* Example:
* TimeZone.getTimeZone(timeZone) is BST
* timeZone is CET
*
* There is one hours difference, which is 3600000 milliseconds
*
*/
this.differenceInHoursMillis = (zoneOffset - defaultOffset);
}
/**
*
* Subtract a number of expire days from the date
*
* #param dateTimeNow - the date and time now
* #return - the date and time minus the number of expired days
* + (difference in hours for timezone * expiryDays)
*
*/
private Date parseDate(Date dateTimeNow) {
return new Date(dateTimeNow.getTime() - (expireDays * DAY_IN_MS) + (this.differenceInHoursMillis * expireDays));
}
private boolean hasDateExpired(Date currentDate) {
Date dateTimeWithExpire = parseDate(currentDate);
return dateTimeWithExpire.before(expiredDate);
}
public static void main(String[] args) throws ParseException {
/* Set the expiry date 7 days, and expireDays = 3
*
* Not expired
*/
Calendar cal = Calendar.getInstance();
cal.add(Calendar.DATE, -7);
ExpiredDate expired = new ExpiredDate("CET", cal.getTime(), 3);
Date dateTimeNow = new Date();
if (expired.hasDateExpired(dateTimeNow)) {
System.out.println("expired");
} else {
System.out.println("NOT expired");
}
/* Set the expiry date / time, and expireDays to 2 days
* Not expired - because the CET timezone adds two hours to the dateTimeWithExpire
*/
cal = Calendar.getInstance();
cal.add(Calendar.DATE, -2);
expired = new ExpiredDate("CET", cal.getTime(), 2);
dateTimeNow = new Date();
if (expired.hasDateExpired(dateTimeNow)) {
System.out.println("expired");
} else {
System.out.println("NOT expired");
}
/* Set the expiry date 1 days, and expireDays = 2
*
* expired
*/
cal = Calendar.getInstance();
cal.add(Calendar.DATE, -1);
expired = new ExpiredDate("CET", cal.getTime(), 2);
dateTimeNow = new Date();
if (expired.hasDateExpired(dateTimeNow)) {
System.out.println("expired");
} else {
System.out.println("NOT expired");
}
}
}

Java.util.Date() behavior [duplicate]

I am doing some date calculations in Java using milliseconds and noticing an issue with the following:
private static final int MILLIS_IN_SECOND = 1000;
private static final int SECONDS_IN_MINUTE = 60;
private static final int MINUTES_IN_HOUR = 60;
private static final int HOURS_IN_DAY = 24;
private static final int DAYS_IN_YEAR = 365; //I know this value is more like 365.24...
private static final long MILLISECONDS_IN_YEAR = MILLIS_IN_SECOND * SECONDS_IN_MINUTE * MINUTES_IN_HOUR * HOURS_IN_DAY * DAYS_IN_YEAR;
System.out.println(MILLISECONDS_IN_YEAR); //Returns 1471228928
I know that that 1 Year is roughly = 31,556,952,000 Milliseconds, so my multiplication is off somehow.
Can anyone point out what I am doing wrong? Should I be using a long?

Should I be using a long?
Yes. The problem is that, since MILLIS_IN_SECOND and so on are all ints, when you multiply them you get an int. You're converting that int to a long, but only after the int multiplication has already resulted in the wrong answer.
To fix this, you can cast the first one to a long:
private static final long MILLISECONDS_IN_YEAR =
(long)MILLIS_IN_SECOND * SECONDS_IN_MINUTE * MINUTES_IN_HOUR
* HOURS_IN_DAY * DAYS_IN_YEAR;

If on android, I suggest:
android.text.format.DateUtils
DateUtils.SECOND_IN_MILLIS
DateUtils.MINUTE_IN_MILLIS
DateUtils.HOUR_IN_MILLIS
DateUtils.DAY_IN_MILLIS
DateUtils.WEEK_IN_MILLIS
DateUtils.YEAR_IN_MILLIS

While others have already pointed out arithmetic overflow, you can also try TimeUnit to solve the problem:
Calendar calendar = Calendar.getInstance();
calendar.set(Calendar.YEAR, year);
int daysInYear = calendar.getActualMaximum(Calendar.DAY_OF_YEAR);
System.out.println(TimeUnit.DAYS.toMillis(daysInYear));

private static final long MILLISECONDS_IN_YEAR = MILLIS_IN_SECOND * ...
All the operands on the right hand side are ints, so the multiplication is done with 32bit signed integers, which overflows. Cast the first one to long and you'll get the expected value.
private static final long MILLISECONDS_IN_YEAR = (long)MILLIS_IN_SECOND * ...

You're overflowing the int type. In Java, the result of a primitive arithmethic operation over two ints is an int. The type of the operands decides this, not the type of the result variable. Try:
private static final int MILLIS_IN_SECOND = 1000;
private static final int SECONDS_IN_MINUTE = 60;
private static final int MINUTES_IN_HOUR = 60;
private static final int HOURS_IN_DAY = 24;
private static final int DAYS_IN_YEAR = 365; //I know this value is more like 365.24...
private static final long MILLISECONDS_IN_YEAR = (long) MILLIS_IN_SECOND * SECONDS_IN_MINUTE * MINUTES_IN_HOUR * HOURS_IN_DAY * DAYS_IN_YEAR;

You need a long. Ints wrap around 2 billion.

To fix this, you can put the letter L after the first one: e.g. 1000L
long MILLS_IN_YEAR = 1000L * 60 * 60 * 24 * 365; // Returns 31536000000

tl;dr
The Answer by Ruakh is correct about your use of int vs long (integer overflow) being the cause of a totally wrong number, 1471228928. But furthermore, your Question raises issue of solar year versus calendar year.
I know that that 1 Year = 31556952000 Milliseconds
No, that would be the length of a solar year, not a calendar year. A calendar year is 31,536,000,000 milliseconds.
The modern java.time classes and ChronoUnit can calculate the calendar year number.
Year y = Year.now( // Determine the year of the current date (today).
ZoneId.of( "America/Montreal" ) // Determining the year means determining the current date. And determining a date requires a time zone. For any given moment, the date varies around the globe by zone.
) ; // Returns a `Year` object.
long millisInYear =
ChronoUnit.MILLIS.between(
y.atDay( 1 ) // Get the first of the year. Returns a `LocalDate`.
.atStartOfDay( // Determine the first moment of the day. Not always 00:00:00 because of anomalies such as Daylight Saving Time (DST).
ZoneId.of( "America/Montreal" )
) // Returns a `ZonedDateTime` object.
,
y.plusYears(1) // Move to the following year.
.atDay( 1 ) // Get the first of the following year. Returns a `LocalDate`.
.atStartOfDay(
ZoneId.of( "America/Montreal" )
) // Returns a `ZonedDateTime` object.
) ;
31536000000
31,556,952,000 = Solar year
Your source is using an approximation of the length of a solar year, about 365.2425 24-hour days. This is the amount of time it takes the earth to orbit the sun.
The math:
365.2425 * 24 * 60 * 60 * 1000 = 31,556,951,999.999996 ≈ 31,556,952,000 ms
See this calculator.
31,536,000,000 = Calendar year
In the Western calendar (Gregorian/ISO), we use years of an even 365 24-hour days, ignoring the fact that the earth's orbit around the sun takes an extra quarter day. We make up for the discrepancy by inserting an extra day every four years (roughly, years which are multiples of four with the exception of years divisible by 100 but not by 400), the Leap Day.
Considering a plain year of 365 days with 24-hour days and no anomalies to account for such as Daylight Saving Time (DST), a calendar year is 31,536,000,000 milliseconds long. Not 31,556,952,000 as you suggest in your Question.
31,536,000,000 = ( 365 * 24 * 60 * 60 * 1000 )
See this calculator.
A Leap Year with 366 days will be 31,622,400,000 milliseconds.
31,622,400,000 = ( 366 * 24 * 60 * 60 * 1000 )
java.time
The modern java.time classes supplant the old date-time classes bundled with the earliest versions of Java. Those old classes have proven to be confusing and troublesome.
ChronoUnit
Leap year and other anomalies might mean an unexpected number of milliseconds in a year. So you should let java.time do an actual calculation, if precision is important in your situation.
The ChronoUnit class can calculate elapsed time in a certain unit.
long millisInYear = ChronoUnit.MILLIS.between( start , stop );
We need to determine the exact moment of the start of the first day day of the year and of the following year. We do that by going through the LocalDate class, which represents a date-only value without a time-of-day and without a time zone.
LocalDate startLd = LocalDate.of ( 2015 , 1 , 1 );
LocalDate stopLd = startLd.plusYears ( 1 );
By assigning a time zone (ZoneId) we get ZonedDateTime objects for specific moments on the timeline.
ZoneId z = ZoneId.of ( "America/Montreal" );
ZonedDateTime start = startLd.atStartOfDay ( z );
ZonedDateTime stop = stopLd.atStartOfDay ( z );
Lastly, calculate the elapsed time in milliseconds.
long millisInYear = ChronoUnit.MILLIS.between ( start , stop );
start.toString(): 2015-01-01T00:00-05:00[America/Montreal]
stop.toString(): 2016-01-01T00:00-05:00[America/Montreal]
millisInYear: 31536000000
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.
You may exchange java.time objects directly with your database. Use a JDBC driver compliant with JDBC 4.2 or later. No need for strings, no need for java.sql.* classes.
Where to obtain the java.time classes?
Java SE 8, Java SE 9, Java SE 10, 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 (<26), 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.

try this
int MILLIS_IN_SECOND = 1000;
int SECONDS_IN_MINUTE = 60;
int MINUTES_IN_HOUR = 60;
int HOURS_IN_DAY = 24;
int DAYS_IN_YEAR = 365;
long MILLISECONDS_IN_YEAR = (long) MILLIS_IN_SECOND * SECONDS_IN_MINUTE * MINUTES_IN_HOUR * HOURS_IN_DAY * DAYS_IN_YEAR;
System.out.println(MILLISECONDS_IN_YEAR); // Returns 31536000000

How can I compare two Calendar dates?

I have a Java problem where I need to check if an item has expired. This is supposed to check if the item is at least x (x is an integer and can be set to any integer value) months old.
Just to reclarify Supposing I have a pack of eggs, I want to check if it has been 1 months since I added them (dateAdded).
I wrote a simple comparison but it doesn't seem to give the correct response. Here is the code.
public Boolean isEndOfLine() {
Calendar today = Calendar.getInstance();
if(today.compareTo(dateAdded) >= END_OF_LINE) {
return true;
} else {
return false;
}
}
The value of end of line is an integer 12 i.e 12 months.

I do not hold javadoc in my head, but along the lines of:
dateAdded.add(Calendar.Month, END_OF_LINE).compareTo(today) > 0

Here's some similar example code, but using the Joda-Time 2.3 library.
FYI:
A Joda-Time DateTime instance knows its own time zone.
The minusMonths method is smart, handles Daylight Saving Time and other issues. You may want to read its source code to verify its logic follows your business rules as to what "x number of months ago" means.
// © 2013 Basil Bourque. This source code may be used freely forever by anyone taking full responsibility for doing so.
// import org.joda.time.*;
// import org.joda.time.format.*;
// Better to specify a time zone explicitly rather than rely on default.
// Time Zone list… http://joda-time.sourceforge.net/timezones.html (not quite up-to-date, read page for details)
DateTimeZone timeZone = DateTimeZone.forID( "Europe/Paris" );
int countMonths = 2;
DateTime now = new DateTime( timeZone );
// If you want to include the entire day, get first moment of the day by calling "withTimeAtStartOfDay".
DateTime someMonthsAgo = now.minusMonths( countMonths ).withTimeAtStartOfDay();
DateTime dateAdded = new DateTime( 2013, 5, 6, 7, 8, 9, timeZone ); // Arbitrary values for example.
// If 'dateAdded' happened prior to our target date-time 'someMonthsAgo', the pack of eggs is expired.
Boolean isEndOfLine = dateAdded.isBefore( someMonthsAgo );
Dump to console…
System.out.println( "now: " + now );
System.out.println( "someMonthsAgo: " + someMonthsAgo );
System.out.println( "dateAdded: " + dateAdded );
System.out.println( "isEndOfLine: " + isEndOfLine );
When run…
now: 2014-01-08T21:36:11.179+01:00
someMonthsAgo: 2013-11-08T00:00:00.000+01:00
dateAdded: 2013-05-06T07:08:09.000+02:00
isEndOfLine: true

as mentioned in the Calendar docs
You should not rely on the number returned by compareTo - you just know that if it is greater than 0 that the original date is greater.
So create a new date (x months in the passed) and compare to that one.

The method returns 0 if the time represented by the argument is equal to the time represented by this Calendar object; or a value less than 0 if the time of this Calendar is before the time represented by the argument; or a value greater than 0 if the time of this Calendar is after the time represented.
import java.util.*;
public class CalendarDemo {
public static void main(String[] args) {
// create two calendar at the different dates
Calendar cal1 = new GregorianCalendar(2015, 8, 15);
Calendar cal2 = new GregorianCalendar(2008, 1, 02);
// compare the time values represented by two calendar objects.
int i = cal1.compareTo(cal2);
// return positive value if equals else return negative value
System.out.println("The result is :"+i);
// compare again but with the two calendars swapped
int j = cal2.compareTo(cal);
// return positive value if equals else return negative value
System.out.println("The result is :" + j);
}
}

Here is the working solution. Tested with JUNIT to confirm results.
public Boolean isEndOfLine() {
Calendar today = Calendar.getInstance();
today.add(Calendar.MONTH, -END_OF_LINE);
return today.compareTo(dateAdded) >= 0;
}
I subtracted the END_OF_LINE from today using the add method. Notice the minus on line 3. I then compared to see if it is greater than 0. Thanks for all your suggestions.

Bug in Java Calendar / Date for 2nd October 2010?

I'm not sure what I'm doing wrong, but I've got a piece of code which calculates the number of days between two dates, and which looks something like the following:
final Calendar first = new GregorianCalendar(2010, Calendar.OCTOBER, 1);
final Calendar last = new GregorianCalendar(2010, Calendar.NOVEMBER, 1);
final long difference = last.getTimeInMillis() - first.getTimeInMillis();
final long days = difference / (1000 * 60 * 60 * 24);
System.out.println("difference: " + difference);
System.out.println("days: " + days);
To summarise, the code block above calculates the number of days between 1st October 2010 and 1 November 2010. I'm expecting to see it return 31 days (seeing as there's 31 days in October)
difference: xxxx
days: 31
but instead it's showing 30 days in October!
difference: 2674800000
days: 30
I've managed to narrow it down to between the the dates 2 October 2010 and 3 October 2010, which seems to only have 82800000 milliseconds, instead of a full 86400000 milliseconds (exactly one hour missing).
Does anyone have any ideas what I'm doing wrong? Or is the 2nd October a special date which has one minute less than a regular day?

(86400000 - 82800000)/1000 = 3600, which is one hour. You're seeing daylight savings time, combined with the rounding of integer math
You could get around it by doing the calculations with floating point numbers and rounding at the end, or you could check out a library like Joda time which offers much better date math than what's built in.

You may be better off comparing the year and day or year instead of the milliseconds that pass in a day.
int lastYear= last.get(Calendar.YEAR);
int firstYear= first.get(Calendar.YEAR);
int lastDayofYear = last.get(Calendar.DAY_OF_YEAR);
int firstDayofYear = first.get(Calendar.DAY_OF_YEAR);
int nDaysElapse = lastDayofYear - firstDayofYear;
int nYearsElapse = lastYear- firstYear;
int days = (nYearsElapse*365)+nDaysElapse;

You should read this post to get a better understanding of how Calendar is interrelated with date/time stamps.
Having read that site, my initial questions were:
What do you mean by days? Do you mean '24-hour blocks' or do you mean calendar days? In the same vein, do you care if you are off slightly due to daylight savings etc?
If you mean Calendar days, your best bet is probably to:
final Calendar first = new GregorianCalendar(2010, 9, 1);
final Calendar last = new GregorianCalendar(2010, 10, 1);
Calendar difference = Calendar.getInstance();
difference.setTimeInMillis(last.getTimeInMillis() - first.getTimeInMillis());
int numDays = difference.get(Calendar.DAY_OF_YEAR) - difference.getMinimum(Calendar.DAY_OF_YEAR);
Of course, the above code will only work if the number of days < 365. You will need to create a rolling calculation e.g.
int yearDiff = last.get(Calendar.YEAR) - first.get(Calendar.YEAR);
Calendar tmp = new GregorianCalendar();
tmp.setTimeInMillis(first.getTimeInMillis());
for(int i = 0; i < yearDiff; i++) {
numDays += tmp.getActualMaximum(Calendar.DAY_OF_YEAR);
i++;
tmp.add(Calendar.YEAR, 1);
}
This should allow you to get the number of days in a correct and consistent manner, without worrying about Daylight Savings, Leap Years etc.
That said, JodaTime probably has this functionality built in.

The answer by Brad Mace is correct.
Use a Library
This question is a good example of why you should use a good date-time library wither than roll your own. For Java that means using either Joda-Time or the new java.time package in Java 8.
Joda-Time
Example code in Joda-Time.
DateTimeZone timeZone = DateTimeZone.forID( "Australia/Melbourne" );
DateTime theFirst = new DateTime( 2014, DateTimeConstants.OCTOBER, 1, 0, 0, 0, timeZone ).withTimeAtStartOfDay();
DateTime nextMonth = theFirst.plusMonths( 1 ).withTimeAtStartOfDay();
int days = Days.daysBetween( theFirst, nextMonth ).getDays();
Or if you don't care about time-of-day, use the LocalDate class.
java.time
Java 8 and later comes with a new java.time framework to supplant the old java.util.Date/.Calendar classes. Inspired by Joda-Time, defined by JSR 310, and extended by the ThreeTen-Extra project.
Example code using Java 8. Note that the enum ChronoUnit returns a 64-bit long rather than int.
LocalDate firstOfOctober = LocalDate.of( 2010 , java.time.Month.OCTOBER , 1 );
LocalDate nextMonth = firstOfOctober.plusMonths( 1 );
long daysInMonth = ChronoUnit.DAYS.between( firstOfOctober , nextMonth );

The code you put in your post is calculating the time between September 1 and October 1, not October 1 and November 1. The output is correct for the code you posted.