Develop Reference

How would I convert the exact amount of time (years, months, days, hours, minutes, seconds) between two Calendar objects?

I am trying to covert the exact amount of time between two Calendar objects in Java.
This is the code that I currently have...
public static Map<TimeUnit, Long> computeDifference(Calendar date1, Calendar date2) {
long diffInMillies = date2.getTimeInMillis() - date1.getTimeInMillis();
//create the list
List<TimeUnit> units = new ArrayList<TimeUnit>();
units.add(TimeUnit.SECONDS);
units.add(TimeUnit.MINUTES);
units.add(TimeUnit.HOURS);
units.add(TimeUnit.DAYS);
Collections.reverse(units);
//create the result map of TimeUnit and difference
Map<TimeUnit,Long> result = new LinkedHashMap<TimeUnit,Long>();
long milliesRest = diffInMillies;
for ( TimeUnit unit : units ) {
//calculate difference in millisecond
long diff = unit.convert(milliesRest,TimeUnit.MILLISECONDS);
long diffInMilliesForUnit = unit.toMillis(diff);
milliesRest = milliesRest - diffInMilliesForUnit;
//put the result in the map
result.put(unit,diff);
}
return result;
}
When printed, the output looks like this {DAYS=1, HOURS=10, MINUTES=30, SECONDS=45} for input date1 = 19 August 2019 02:00:00 and date2 = 20 August 2019 12:30:45
The largest time unit available in this method is DAYS, but I want to find something that includes both months and years. I realize that TimeUnit doesn't really have anything to do with specific calendar dates (rather a 24-hour interval), which is why I was wondering if there is any way to make this conversion using the Calendar class or something similar. I've also looked into ChronoUnit as a substitute for TimeUnit, but that won't work for the same reason TimeUnit doesn't.
Would love any suggestions for how to incorporate larger time units. Thank you!

You shouldn't use the Calendar class, since it's obsolete. You should use classes from the java.time package instead.
In order to get the desired result, you could use the Period class.
You first need to convert both Calendar instances to LocalDate instances.
Then you could use Period.between(startDate, endDate) to get a Period instance, which makes the getDays(), getMonths() and getYears() methods available to you.
If you also want to include time components (hours, minutes and seconds), then you could use Duration in combination with Period. But then first read the post linked to by Sweeper.
Something like this would probably work:
LocalDateTime start = LocalDateTime.of(2019, 1, 1, 12, 0, 0);
LocalDateTime end = LocalDateTime.of(2021, 4, 26, 5, 56, 40);
Duration d = Duration.between(start.toLocalTime(), end.toLocalTime());
Period p = Period.between(start.toLocalDate(), end.toLocalDate());
// If the startdate's time component lies behind the enddate's time component,
// then we need to correct both the Period and Duration
if (d.isNegative()) {
p = p.minusDays(1);
d = d.plusDays(1);
}
System.out.printf("y %s m %s d %s h %s m %s s %s%n",
p.getYears(),
p.getMonths(),
p.getDays(),
d.toHours() % 24,
d.toMinutes() % 60,
d.getSeconds() % 60);
Note that Java 9 comes with to…Part methods, so you don't have to use the modulo operator anymore.
Be advised: this code does not take into account clock adjustments due to daylight savings time.

tl;dr
Period
.between(
( ( GregorianCalendar ) myCalStart ).toZonedDateTime().toLocalDate() ,
( ( GregorianCalendar ) myCalStop ).toZonedDateTime().toLocalDate()
)
…or…
Duration
.between(
( ( GregorianCalendar ) myCalStart ).toInstant() ,
( ( GregorianCalendar ) myCalStop ).toInstant()
)
java.time
You are using terrible date-time classes that were supplanted years ago by the modern java.time classes defined in JSR 310.
Never use Calendar, GregorianCalendar, Date, SimpleDateFormat, and such. Use only the classes found in the java.time packages.
ZonedDateTime
Assuming both your Calendar objects are actually GregorianCalendar objects underneath, convert. To convert, call new to…/from… methods added to the old classes.
// start
GregorianCalendar gcStart = ( GregorianCalendar ) myCalStart ;
ZonedDateTime zdtStart = gcStart.toZonedDateTime() ;
// stop
GregorianCalendar gcStop = ( GregorianCalendar ) myCalStop ;
ZonedDateTime zdtStop = gcStop.toZonedDateTime() ;
Both GregorianCalendar and ZonedDateTime represent a date with a time-of-day placed in the context of a time zone, combined to determine a moment (a specific point on the timeline). ZonedDateTime resolves to a finer level of nanoseconds rather than milliseconds.
Period
If you care about elapsed time in terms of years-months-days, use Period with LocalDate objects. LocalDate represents a date without a time-of-day and without a time zone. We can extract the date portion from our ZonedDateTime objects.
LocalDate ldStart = zdtStart.toLocalDate() ;
LocalDate ldStop = zdtStop.toLocalDate() ;
Period p = Period.between( ldStart , ldStop ) ;
Generate a string in standard ISO 8601 format.
String output = p.toString() ;
Interrogate for a count of years, months, days.
int years = p.getYears() ;
int months = p.getMonths() ;
int days = p.getDays() ;
Duration
If you cane about elapsed time in terms of hours-minutes-seconds, use Duration. This class represent a pair of moments in UTC. So we extract Instant objects from our pair of ZonedDateTime objects, which internally keep a count of whole seconds since the epoch reference of first moment of 1970 in UTC, plus a fractional second as a count of nanoseconds.
Instant instantStart = zdtStart.toInstant() ;
Instant instantStop = zdtStop.toInstant() ;
Duration d = Duration.between( instantStart , instantStop ) ;
Generate a string in standard ISO 8601 format.
String output = d.toString() ;
Interrogate for a count of days (as 24-hour chunks of time unrelated to the calendar), hours, minutes, seconds.
long days = d.toDaysPart() ;
int hours = d.toHoursPart() ;
int minutes = d.toMinutesPart() ;
int seconds = d.toSecondsPart() ;
int nanos = d.toNanosPart() ;
PeriodDuration
If you think about it, you will see that it does not make sense to combine years/months/days with 24-hour-days/hours/minutes/seconds. See this Stack Overflow page as food for thought.
But if you insist on combining these two different concepts, see the PeriodDuration class found in the ThreeTen-Extra library.

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");
}
}
}

How many instances of a partial date (month & day) appear in a range, and its day of the week

In Java, how would I go about constructing a utility that would take a range of dates (start and end date) and then would see how many times a given partial date ( the month and day-of-month) appears in that range, and will add an entry to a list for each match.
In my instance, I want to give it a range of say 5 years - starting Jan 1st 2014 and going to Dec 31st 2019. My check date is the 2nd August. I want the method to return the full information about each match of any August 2 of any year in the range. So for 2014 is will return Saturday 2nd August 2014, then Sunday 2nd August 2015 etc and so on.
I've been trying to get something working so far with Joda Time and the default date/calendar classes in Java and I'm just getting myself in a mess.
Thanks,
S
Edit: How silly of me, apologies for not adding my code :(
public static List<Date> getDaysInRange(Date startdate,
Date enddate,
Date checkDate) {
SimpleDateFormat sdf = new SimpleDateFormat("MMdd");
List<Date> dates = new ArrayList<>();
Calendar cal = new GregorianCalendar();
cal.setTime(startdate);
while (cal.getTime().before(enddate)) {
if (sdf.format(cal.getTime()).equals(sdf.format(checkDate))) {
Date result = cal.getTime();
dates.add(result);
}
cal.add(Calendar.DATE, 1);
}
return dates;
}

Date-Only
Since you want only a date without time-of-day and without time zone, use a date-only class. The old java.util.Date/.Calendar classes lack such a class. And those old classes are notoriously troublesome and flawed.
Instead use either:
Joda-Time
java.time, built into Java 8, inspired by Joda-Time.
Joda-Time
Here is some untested code using Joda-Time 2.6.
The main idea is to focus on the small set of possible year numbers rather than test every day of year. In the example below, that means six date-time values to compare rather than thousands. Besides efficiency, the purpose of the code becomes more apparent.
The arguments to your routine should be a month number and a day-of-month number, a pair of ints or Integers, rather than a Date. As seen in this examples two int variables, month and day.
LocalDate start = new LocalDate( 2011, 2, 3 );
LocalDate stop = new LocalDate( 2016, 4, 5 );
int yearStart = start.getYear();
int yearStop = stop.getYear();
int month = 11;
int day = 22;
for ( i = yearStart, i <= yearStop, i++ )
{
LocalDate x = new LocalDate( i, month, day );
boolean matchStart = ( x.isEqual( start ) || x.isAfter( start ) );
boolean matchStop = x.isBefore( stop ); // Half-Open approach where beginning of range is inclusive while ending is exclusive.
if ( matchStart && matchStop )
{
// Add to collection of LocalDate objects.
// Later you can ask each LocalDate object for its day-of-week.
{
}
java.time
The java.time package also offers a LocalDate class. The code would be similar to the above Joda-Time example.

I think using SimpleDateFormat is a bad idea. Use Calendar for comparison directly, like this
cal1.get(Calendar.MONTH) == cal2.get(Calendar.MONTH) && cal1.get(Calendar.DAY_OF_MONTH) == cal2.get(Calendar.DAY_OF_MONTH)

See if the current time falls within a specific range of time in the current day in Java

I am sure this was done 1000 times in 1000 different places. The question is I want to know if there is a better/standard/faster way to check if current "time" is between two time values given in hh:mm:ss format. For example, my big business logic should not run between 18:00:00 and 18:30:00. So here is what I had in mind:
public static boolean isCurrentTimeBetween(String starthhmmss, String endhhmmss) throws ParseException{
DateFormat hhmmssFormat = new SimpleDateFormat("yyyyMMddhh:mm:ss");
Date now = new Date();
String yyyMMdd = hhmmssFormat.format(now).substring(0, 8);
return(hhmmssFormat.parse(yyyMMdd+starthhmmss).before(now) &&
hhmmssFormat.parse(yyyMMdd+endhhmmss).after(now));
}
Example test case:
String doNotRunBetween="18:00:00,18:30:00";//read from props file
String[] hhmmss = downTime.split(",");
if(isCurrentTimeBetween(hhmmss[0], hhmmss[1])){
System.out.println("NOT OK TO RUN");
}else{
System.out.println("OK TO RUN");
}
What I am looking for is code that is better
in performance
in looks
in correctness
What I am not looking for
third-party libraries
Exception handling debate
variable naming conventions
method modifier issues

this is all you should need to do, this method is loosely coupled from the input and highly coherent.
boolean isNowBetweenDateTime(final Date s, final Date e)
{
final Date now = new Date();
return now.after(s) && now.before(e);
}
how you get the Date objects for start and end is irrelevant to comparing them. You are making things way more complicated than you need to with passing String representations around.
Here is a better way to get the start and end dates, again loosely coupled and highly coherent.
private Date dateFromHourMinSec(final String hhmmss)
{
if (hhmmss.matches("^[0-2][0-9]:[0-5][0-9]:[0-5][0-9]$"))
{
final String[] hms = hhmmss.split(":");
final GregorianCalendar gc = new GregorianCalendar();
gc.set(Calendar.HOUR_OF_DAY, Integer.parseInt(hms[0]));
gc.set(Calendar.MINUTE, Integer.parseInt(hms[1]));
gc.set(Calendar.SECOND, Integer.parseInt(hms[2]));
gc.set(Calendar.MILLISECOND, 0);
return gc.getTime();
}
else
{
throw new IllegalArgumentException(hhmmss + " is not a valid time, expecting HH:MM:SS format");
}
}
Now you can make two well named method calls that will be pretty self documenting.

tl;dr
LocalTime now =
ZonedDateTime
.now( ZoneId.of( "America/Montreal" ) )
.toLocalTime() ;
Boolean isBetween =
( ! now.isBefore( LocalTime.of( 18 , 0 ) ) // "not before" means "is equal to OR after".
&&
now.isBefore( LocalTime.of( 18 , 30 ) ) ; // Half-Open, beginning is *inclusive* while ending is *exclusive*.
Using java.time
You are using old date-time classes that have proven to be poorly designed, confusing, and troublesome. They are now legacy, supplanted by the java.time classes.
LocalTime
Do not pass mere strings representing time-of-day values. We now have a type for that, the LocalTime class.
LocalTime start = LocalTime.of( 18 , 0 );
LocalTime stop = LocalTime.of( 18 , 30 );
Pass those instances to your utility method. That method should not have to do any parsing, so no need to throw the parsing exception.
public static boolean isCurrentTimeBetween( LocalTime start , LocalTime stop ) {
…
ZonedDateTime
A time zone is crucial in determining the current date and time-of-day. 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.
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" );
ZonedDateTime zdt = ZonedDateTime.now( z );
To compare the time-of-day of now, we could simply extract a LocalTime from that ZonedDateTime. But we have the problem of anomalies, such as Daylight Saving Time (DST) and politicians redefining time zones. There may not be any 6 PM hour on a particular date. The solution to this conundrum depends on your business context and your business rules. You could either ignore the conundrum and stick with literally asking if the current time is between your target start-stop time. Or you could apply the time zone to your start-stop times-of-day of day and let ZonedDateTime class make adjustments as it sees fit. Let's look at both approaches.
Ignore anomalies
First, ignore any anomalies. Ask simply and literally if the current time-of-day is between the target start and stop times-of-day.
We can extract a time-of-day object from the zoned date-time object.
LocalTime localTimeNow = zdt.toLocalTime(); // Extract a time-of-day from the zoned date-time object.
Compare that to our stop-start times-of-day. Note that we use here the Half-Open approach to defining a span of time. In this approach the beginning is inclusive while the ending is exclusive. This approach is common in date-time work and generally is the wise way to go.
Boolean isNowOnOrAfterStart = ( ! localTimeNow.isBefore( start ) ) ; // A briefer way of asking "is equal to OR is after" is "is not before".
Boolean isNowBeforeStop = localTimeNow.isBefore( stop );
Boolean isNowInTargetZone = ( isNowOnOrAfterStart && isNowBeforeStop ); // Half-Open: beginning is inclusive while ending is exclusive.
Consider anomalies
Next we consider any anomalies. We apply the start and stop times-of-day to the current date within the same time zone. We extract the date-only from the zoned date-time object.
LocalDate localDateToday = zdt.toLocalDate();
ZonedDateTime zdtStart = ZonedDateTime.of( localDateToday , start , z );
ZonedDateTime zdtStop = ZonedDateTime.of( localDateToday , stop , z );
Study the class documentation to understand the behavior of ZonedDateTime.of in resolving invalid time-of-day values. There is no perfect way to resolve nonexistent time-of-day values, so you must decide if this class’ way meets your business rules.
ZonedDateTime.of
public static ZonedDateTime of(LocalDate date, LocalTime time, ZoneId zone)
Obtains an instance of ZonedDateTime from a local date and time.
This creates a zoned date-time matching the input local date and time as closely as possible. Time-zone rules, such as daylight savings, mean that not every local date-time is valid for the specified zone, thus the local date-time may be adjusted.
The local date time and first combined to form a local date-time. The local date-time is then resolved to a single instant on the time-line. This is achieved by finding a valid offset from UTC/Greenwich for the local date-time as defined by the rules of the zone ID.
In most cases, there is only one valid offset for a local date-time. In the case of an overlap, when clocks are set back, there are two valid offsets. This method uses the earlier offset typically corresponding to "summer".
In the case of a gap, when clocks jump forward, there is no valid offset. Instead, the local date-time is adjusted to be later by the length of the gap. For a typical one hour daylight savings change, the local date-time will be moved one hour later into the offset typically corresponding to "summer".
Apply the same comparison logic as we saw above.
Boolean isNowOnOrAfterStart = ( ! zdt.isBefore( zdtStart ) ) ; // A briefer way of asking "is equal to OR is after" is "is not before".
Boolean isNowBeforeStop = zdt.isBefore( zdtStop );
Boolean isNowInTargetZone = ( isNowOnOrAfterStart && isNowBeforeStop ); // Half-Open: beginning is inclusive while ending is exclusive.
Alternative way to make the comparison is to use the handy Interval class from the ThreeTen-Extra project. That class takes a pain of Instant objects, which you can extract from your ZonedDateTime objects. The Instant class represents a moment on the timeline in UTC with a resolution of nanoseconds (up to nine (9) digits of a decimal fraction).
Interval interval = Interval.of( zdtStart.toInstant() , zdtStop.toInstant() );
Boolean isNowInTargetZone = interval.contains( zdt.toInstant() );
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.

As pointed out by Kevin, Fuzzy Lollipop's Regex won't pick up times between 14:00 and 19:00.
To get match a full 24 hour clock, you can use this:
if (hhmmss.matches("^([0-1][0-9]|2[0-3]):([0-5][0-9]):([0-5][0-9])$"))
{
// Do stuff here
}

The following Class is something I just created out of some of the code from other answers. It encapsulates the behavior of a 'time period' without relating to specific days. Our system is using this Class to check if the current time is within one of our designated maintenance windows. i.e. 05:00:00 - 07:00:00
import java.util.Calendar;
import java.util.Date;
import java.util.GregorianCalendar;
/**
*
* #author Adam Yocum
*/
public class ExclusionTimePeriod {
private String timeStart;
private String timeEnd;
/**
* #return the timeStart
*/
public String getTimeStart() {
return timeStart;
}
/**
* #param timeStart the timeStart to set
*/
public void setTimeStart(String timeStart) {
if (timeStart.matches("^([0-1][0-9]|2[0-3]):([0-5][0-9]):([0-5][0-9])$"))
{
this.timeStart = timeStart;
}
else
{
throw new IllegalArgumentException(timeStart + " is not a valid time, expecting HH:MM:SS format");
}
}
/**
* #return the timeEnd
*/
public String getTimeEnd() {
return timeEnd;
}
/**
* #param timeEnd the timeEnd to set
*/
public void setTimeEnd(String timeEnd) {
if (timeEnd.matches("^([0-1][0-9]|2[0-3]):([0-5][0-9]):([0-5][0-9])$"))
{
this.timeEnd = timeEnd;
}
else
{
throw new IllegalArgumentException(timeEnd + " is not a valid time, expecting HH:MM:SS format");
}
}
private Date toDate(String hhmmss){
final String[] hms = hhmmss.split(":");
final GregorianCalendar gc = new GregorianCalendar();
gc.set(Calendar.HOUR_OF_DAY, Integer.parseInt(hms[0]));
gc.set(Calendar.MINUTE, Integer.parseInt(hms[1]));
gc.set(Calendar.SECOND, Integer.parseInt(hms[2]));
gc.set(Calendar.MILLISECOND, 0);
Date date = gc.getTime();
return date;
}
public boolean isNowInPeriod()
{
final Date now = new Date();
return now.after(toDate(getTimeStart())) && now.before(toDate(getTimeEnd()));
}
public static void main(String[] args){
//Test All possible hours
for(int hour=0;hour<=23;hour++){
String hourStr = "";
if(hour<=9){
hourStr = "0"+hour;
}else{
hourStr = ""+hour;
}
for(int min=0;min<60;min++){
String minStr = "";
if(min<=9){
minStr = "0"+min;
}else{
minStr = ""+min;
}
for(int sec=0;sec<60;sec++){
String secStr = "";
if(sec<=9){
secStr = "0"+sec;
}else{
secStr = ""+sec;
}
String hhmmss = hourStr+":"+minStr+":"+secStr;
ExclusionTimePeriod period = new ExclusionTimePeriod();
period.setTimeStart(hhmmss);
period.setTimeEnd(hhmmss);
System.out.println(hhmmss+" Ok");
}
}
}
//Test isInPeriod functionality
ExclusionTimePeriod isInTest = new ExclusionTimePeriod();
isInTest.setTimeStart("10:00:00");
isInTest.setTimeEnd("10:43:00");
System.out.println((new Date())+" is between "+isInTest.getTimeStart()+" and "+isInTest.getTimeEnd()+" = "+isInTest.isNowInPeriod());
}
}

The Midnight Problem
Other answers fail to mention it - and the OP doesn't ask - but you should really consider when the interval spans across midnight.
Time is difficult. I purposely left the "long" version of the code and didn't abbreviate logical conditions to make it as clear as possible the what's and the why's.
/**
* Takes into consideration that the interval may span accross midnight
*
* #param clock to make unit testing easier, just replace for Clock.systemUTC() in your code
* #param start the interval start
* #param end the interval end
* #return true if "now" is inside the specified interval
*/
static boolean isNowBetweenLocalTime(Clock clock, final LocalTime start, final LocalTime end) {
LocalTime now = LocalTime.now(clock);
// if interval crosses midnight
if (end.isBefore(start)) {
if (now.isAfter(start) && now.isAfter(end)) {
return true;
}
if (now.isBefore(start) && now.isBefore(end)) {
return true;
}
return false;
}
// if interval does not cross midnight
if (end.isAfter(start)) {
if (now.isAfter(start) && now.isBefore(end)) {
return true;
}
return false;
}
return false; // interval is 0 so start and end always outside interval
}
Verbosity is not always wrong. This method will be buried in a utility class and two years from now you'll thank yourself for understanding what it does!

The dateFromHourMinSec method is flawed as written. It won't allow any hours where the seconde digit is greater than 3, e.g. 18:00:00. If you change it to allow [0-2][0-9] it will allow times such as 29:00:00.
Have a fix for that?

Get integer value of the current year in Java

I need to determine the current year in Java as an integer. I could just use java.util.Date(), but it is deprecated.

For Java 8 onwards:
int year = Year.now().getValue();
For older version of Java:
int year = Calendar.getInstance().get(Calendar.YEAR);

Using Java 8's time API (assuming you are happy to get the year in your system's default time zone), you could use the Year::now method:
int year = Year.now().getValue();

This simplest (using Calendar, sorry) is:
int year = Calendar.getInstance().get(Calendar.YEAR);
There is also the new Date and Time API JSR, as well as Joda Time

You can also use 2 methods from java.time.YearMonth( Since Java 8 ):
import java.time.YearMonth;
...
int year = YearMonth.now().getYear();
int month = YearMonth.now().getMonthValue();

tl;dr
ZonedDateTime.now( ZoneId.of( "Africa/Casablanca" ) )
.getYear()
Time Zone
The answer by Raffi Khatchadourian wisely shows how to use the new java.time package in Java 8. But that answer fails to address the critical issue of time zone in determining a date.
int year = LocalDate.now().getYear();
That code depends on the JVM's current default time zone. The default zone is used in determining what today’s date is. Remember, for example, that in the moment after midnight in Paris the date in Montréal is still 'yesterday'.
So your results may vary by what machine it runs on, a user/admin changing the host OS time zone, or any Java code at any moment changing the JVM's current default. Better to specify the time zone.
By the way, always use proper time zone names as defined by the IANA. Never use the 3-4 letter codes that are neither standardized nor unique.
java.time
Example in java.time of Java 8.
int year = ZonedDateTime.now( ZoneId.of( "Africa/Casablanca" ) ).getYear() ;
Joda-Time
Some idea as above, but using the Joda-Time 2.7 library.
int year = DateTime.now( DateTimeZone.forID( "Africa/Casablanca" ) ).getYear() ;
Incrementing/Decrementing Year
If your goal is to jump a year at a time, no need to extract the year number. Both Joda-Time and java.time have methods for adding/subtracting a year at a time. And those methods are smart, handling Daylight Saving Time and other anomalies.
Example in java.time.
ZonedDateTime zdt =
ZonedDateTime
.now( ZoneId.of( "Africa/Casablanca" ) )
.minusYears( 1 )
;
Example in Joda-Time 2.7.
DateTime oneYearAgo = DateTime.now( DateTimeZone.forID( "Africa/Casablanca" ) ).minusYears( 1 ) ;

The easiest way is to get the year from Calendar.
// year is stored as a static member
int year = Calendar.getInstance().get(Calendar.YEAR);

If you want the year of any date object, I used the following method:
public static int getYearFromDate(Date date) {
int result = -1;
if (date != null) {
Calendar cal = Calendar.getInstance();
cal.setTime(date);
result = cal.get(Calendar.YEAR);
}
return result;
}

Use the following code for java 8 :
LocalDate localDate = LocalDate.now();
int year = localDate.getYear();
int month = localDate.getMonthValue();
int date = localDate.getDayOfMonth();

You can also use Java 8's LocalDate:
import java.time.LocalDate;
//...
int year = LocalDate.now().getYear();

If your application is making heavy use of Date and Calendar objects, you really should use Joda Time, because java.util.Date is mutable. java.util.Calendar has performance problems when its fields get updated, and is clunky for datetime arithmetic.

As some people answered above:
If you want to use the variable later, better use:
int year;
year = Calendar.getInstance().get(Calendar.YEAR);
If you need the year for just a condition you better use:
Calendar.getInstance().get(Calendar.YEAR)
For example using it in a do while that checks introduced year is not less than the current year-200 or more than the current year (Could be birth year):
import java.util.Calendar;
import java.util.Scanner;
public static void main (String[] args){
Scanner scannernumber = new Scanner(System.in);
int year;
/*Checks that the year is not higher than the current year, and not less than the current year - 200 years.*/
do{
System.out.print("Year (Between "+((Calendar.getInstance().get(Calendar.YEAR))-200)+" and "+Calendar.getInstance().get(Calendar.YEAR)+") : ");
year = scannernumber.nextInt();
}while(year < ((Calendar.getInstance().get(Calendar.YEAR))-200) || year > Calendar.getInstance().get(Calendar.YEAR));
}

In my case none of the above is worked. So After trying lot of solutions i found below one and it worked for me
import java.util.Scanner;
import java.util.Date;
public class Practice
{
public static void main(String[] args)
{
Date d=new Date();
int year=d.getYear();
int currentYear=year+1900;
System.out.println(currentYear);
}
}

I may add that a simple way to get the current year as an integer is importing
java.time.LocalDate and, then:
import java.time.LocalDate;
int yourVariable = LocalDate.now().getYear()
Hope this helps!

You can do the whole thing using Integer math without needing to instantiate a calendar:
return (System.currentTimeMillis()/1000/3600/24/365.25 +1970);
May be off for an hour or two at new year but I don't get the impression that is an issue?

In Java version 8+ can (advised to) use java.time library. ISO 8601 sets standard way to write dates: YYYY-MM-DD and java.time.Instant uses it, so (for UTC):
import java.time.Instant;
int myYear = Integer.parseInt(Instant.now().toString().substring(0,4));
P.S. just in case (and shorted for getting String, not int), using Calendar looks better and can be made zone-aware.

I use special functions in my library to work with days/month/year ints -
int[] int_dmy( long timestamp ) // remember month is [0..11] !!!
{
Calendar cal = new GregorianCalendar(); cal.setTimeInMillis( timestamp );
return new int[] {
cal.get( Calendar.DATE ), cal.get( Calendar.MONTH ), cal.get( Calendar.YEAR )
};
};
int[] int_dmy( Date d ) {
...
}