Develop Reference

Get number of days since date object, disregard time

I'm unsure whether this can be made more efficient or not, but I need to get the number of days that have passed since a unix/epoch timestamp, where the time itself is not a factor, only the date compared to now.
Example 1:
Timestamp is : 3rd September 14:35
Compared to now which is: 4th September 00:35
Days difference = 1
Example 2:
Timestamp is: 3rd September 23:55
Compared to now which is: 4th September 00:35
Days difference = 1
Example 3:
Timestamp is: 2nd September 02:23
Compared to now which is: 4th September 00:35
Days difference = 2
To get this, I have the following code:
String epoch = "1599134401" // the unix/epoch timestamp in seconds
Long epochMillis = Long.valueOf(epoch) * 1000;
Date epochDateObj = new Date(epochMillis);
Calendar tsCal = Calendar.getInstance();
tsCal.setTime(epochDateObj);
tsCal.set(Calendar.HOUR_OF_DAY, 0);
tsCal.set(Calendar.MINUTE, 0);
tsCal.set(Calendar.SECOND, 0);
tsCal.set(Calendar.MILLISECOND, 0);
Calendar today = Calendar.getInstance();
today.set(Calendar.HOUR_OF_DAY, 0);
today.set(Calendar.MINUTE, 0);
today.set(Calendar.SECOND, 0);
today.set(Calendar.MILLISECOND, 0);
long diffInMillies = Math.abs(today.getTime().getTime() - tsCal.getTime().getTime());
long diff = TimeUnit.DAYS.convert(diffInMillies, TimeUnit.MILLISECONDS);
if(diff > 1) {
return diff + " days";
} else {
return diff + " day";
}
The above code works, but to me, it seems quite elaborate for such a rather small thing as this.
Any suggestions for optimizing it? Maybe there's some functionality I don't know about. Its an Android app which is using a rather old SDK (back to Android 4.1).

Days are quite fundamentally a human concept. They involve politics, opinion, confusion, timezones, eras, epochs, and other very hairy concepts. java.util.Date has no snowball's chance in hades to do it right. Nor does calendar.
Your only hope is a proper API, such as java.time.
Furthermore you need to clean up your question. What you're asking is impossible; you're comparing guns to grandmas. epoch-time is fundamentally a 'computer' concept - it refers solely to moments in time, it has no idea when, where, who, which political party, etc you are asking. Which is a problem, because without any of that information it is NOT possible to know what day it is. Seconds are more or less universal, but days are not. A day can be 23 hours or 25 hours, or 23 hours, 59 minutes and 59 seconds, or 24 hours and 1 second - sometimes whole days get skipped, etcetera. 'how long is a day' is not answerable without knowing who you ask and what timezone (and sometimes, political entity!) is used as context.
So, let's say you're asking someone in arizona. The answer will then depend rather a lot on where in arizona you ask and who you ask: You would need to (potentially) know whether the person you so happen to ask applies daylight savings time or not back in 1970 as well as in the 'target' time. This depends on whether you're asking when you're on an native american reservation within arizona or not, and/or if the person you're asking is sticking to NAR zones or not. Hence why I mentioned the politics thing, and why what you want is completely impossible.
java.time to the rescue which can actually represent the crazy mess!
Instant represents a moment in time. It's internally stored as epoch-millis and cannot tell you the day, month, year, era, hour, etc of that moment in time by itself. That's because.. well, that's because that's how reality works. If I snap my fingers right now, and I ask someone 'what time is it', it depends on where I am and where the person I'm asking is and what political parties they ascribe to, so it's not possible. But, you combine a Zone and an Instant and now we're getting somewhere.
LocalDateTime represents a time as a human would say it: A year/month/day + hour/minute/second. It is not possible to turn this into epochmillis for the same reason in reverse. And for the same reason, if you combine this with a Zone doors start opening.
ZonedDateTime tries to bridge the gap: It represents a time as a human would say it, but we code in the location (and political affiliations) of the human who said it. You can store this either as a LocalDateTime + TimeZone, or as an Instant+TimeZone (you don't need to know how it is implemented, of course). You can move from a ZDT to either Instant or LocalDateTime, of course, and this one can answer many questions.
Let's try to solve your problem:
String epoch = "1599134401"; // the unix/epoch timestamp in seconds
String where = "Europe/Berlin"; // what you want is impossible without this!!
Instant instant = Instant.ofEpochSecond(Long.valueOf(epoch));
ZonedDateTime target = instant.atZone(ZoneId.of(where));
ZonedDateTime today = ZonedDateTime.now(where);
long days = ChronoUnit.DAYS.between(target, today);
System.out.println(days);
As a general rule, if you start doing serious math on dates you're messing up and it won't work. Not that your tests will ever catch it of course; it'll go ape when the clocks go back or forward or some political party decides 5 days before it happens to end daylight savings time, or the client is in one place and your server is in another, etc - all stuff that tests rarely catch.
Proper use of java.time should usually mean you aren't doing much calculation, and so it is here, fortunately.

There’s already a very great and insightful answer by rzwitserloot, I highly recommend it. Just as a minor supplement I wanted to give you my go at the code. Still using java.time, the modern Java date and time API, of course.
ZoneId zone = ZoneId.of("Europe/Tirane");
DateTimeFormatter epochSecondFormatter = new DateTimeFormatterBuilder()
.appendValue(ChronoField.INSTANT_SECONDS)
.toFormatter();
String epoch = "1599134401"; // the unix/epoch timestamp in seconds
Instant then = epochSecondFormatter.parse(epoch, Instant::from);
LocalDate thatDay = then.atZone(zone).toLocalDate();
LocalDate today = LocalDate.now(zone);
long diff = ChronoUnit.DAYS.between(thatDay, today);
diff = Math.abs(diff);
if (diff == 1) {
System.out.println("" + diff + " day");
} else {
System.out.println("" + diff + " days");
}
When I ran the code just now, the output was:
1 day
Since you want to ignore the time of day, LocalDate is the correct class to use for the dates. A LocalDate is a date with time of day and without time zone.
In English (not being a native speaker, though) I prefer saying “0 days”, not “0 day”. So I have changed your condition for choosing between singular and plural.
Did your code work?
Your code gives inaccurate results in corner cases. TimeUnit is generally a fine enum for time unit conversions, but it assumes that a day is always 24 hours, which is not always the case, as rzwitserloot explained. The java.time code of that answer and of this one correctly takes transitions to and from summer time (DST) and other time anomalies into account.
Question: Does java.time work on Android 4.1?
java.time works nicely on both older and newer Android devices. It just requires at least Java 6.
In Java 8 and later and on newer Android devices (from API level 26) the modern API comes built-in.
In non-Android Java 6 and 7 get the ThreeTen Backport, the backport of the modern classes (ThreeTen for JSR 310; see the links at the bottom).
On older Android either use desugaring or the Android edition of ThreeTen Backport. It’s called ThreeTenABP. In the latter case make sure you import the date and time classes from org.threeten.bp with subpackages.
Links
Oracle tutorial: Date Time explaining how to use java.time.
Java Specification Request (JSR) 310, where java.time was first described.
ThreeTen Backport project, the backport of java.time to Java 6 and 7 (ThreeTen for JSR-310).
Java 8+ APIs available through desugaring
ThreeTenABP, Android edition of ThreeTen Backport
Question: How to use ThreeTenABP in Android Project, with a very thorough explanation.

If we don't want to add the ThreeTenABP library to our project, we need to normalize to a date-without-time in UTC, in order to prevent things like Daylight Savings Time to skew the results.
For that, a helper method is appropriate:
static long toDateUtcMillis(Date time) {
// Get year/month/day according to default time zone
Calendar cal = Calendar.getInstance();
cal.setTime(time);
int year = cal.get(Calendar.YEAR);
int month = cal.get(Calendar.MONTH);
int day = cal.get(Calendar.DAY_OF_MONTH);
// Set year/month/day in UTC
cal.setTimeZone(TimeZone.getTimeZone("UTC"));
cal.clear();
cal.set(year, month, day);
return cal.getTimeInMillis();
}
We can now easily calculate the number of days. In the following we return negative value if the dates are reverse. Add call to Math.abs() if that's not desired.
static int daysBetween(Date date1, Date date2) {
long dateMillis1 = toDateUtcMillis(date1);
long dateMillis2 = toDateUtcMillis(date2);
return (int) TimeUnit.MILLISECONDS.toDays(dateMillis2 - dateMillis1);
}
Test
public static void main(String[] args) throws Exception {
test("3 September 2020 14:35", "4 September 2020 00:35");
test("3 September 2020 23:55", "4 September 2020 00:35");
test("2 September 2020 02:23", "4 September 2020 00:35");
}
static void test(String date1, String date2) throws ParseException {
// Parse the date strings in default time zone
SimpleDateFormat format = new SimpleDateFormat("d MMMM yyyy HH:mm", Locale.US);
int days = daysBetween(format.parse(date1), format.parse(date2));
System.out.println("Timestamp is: " + date1);
System.out.println("Compared to: " + date2);
System.out.println("Days difference = " + days);
System.out.println();
}
Output
Timestamp is: 3 September 2020 14:35
Compared to: 4 September 2020 00:35
Days difference = 1
Timestamp is: 3 September 2020 23:55
Compared to: 4 September 2020 00:35
Days difference = 1
Timestamp is: 2 September 2020 02:23
Compared to: 4 September 2020 00:35
Days difference = 2

Date difference in days is different in different location environment

Below is giving me 279 days in local but in different server it is giving me 278 why this happening ?
String sDate = "10-11-2017";
String eDate = "16-08-2018";
Date startDate = new SimpleDateFormat(MsmConstants.DATE_FORMAT).parse(sDate);
Date endDate = new SimpleDateFormat(MsmConstants.DATE_FORMAT).parse(eDate);
long difference = startDate.getTime() - endDate.getTime();
return Math.abs(difference / (1000 * 60 * 60 * 24));

This is probably coming from some kind of rounding combined with a difference in timezones.
Since both operands on the left and right of your / operator are integral types, you are actually losing precision with that operator.
If you change your expression to: (double) difference / (1000 * 60 * 60 * 24)
you will notice that the result is actually: -278.9583333333333
The reason it is not exact days is because of daylight savings and similar date/time adjustments.
If on your PC you have different regional settings from the server, which do not have the same daylight savings, then you might have got a different number, which exceeded 279.
As a sidenote, the Java 7 and earlier date/time API was very buggy. SimpleDateFormat wasn't even thread safe, and there were lots of issues with daylight savings and similar situations. You should really move to Java 8. What you are doing would simply become: Duration.between(startDate, endDate) and the calculation would be done correctly for you.
String sDate = "10-11-2017";
String eDate = "16-08-2018";
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("dd-MM-yyyy");
LocalDateTime startDate = LocalDate.parse(sDate, formatter).atTime(0, 0);
LocalDateTime endDate = LocalDate.parse(eDate, formatter).atTime(0, 0);
return Duration.between(startDate, endDate).toDays();
You will see that this actually gives you 279.

jbx has already in another answer explained nicely what went wrong. 10 November is in winter on the Northern hemisphere, and 16 August is in summer. Between those two dates summer time (DST) begins, which causes one day to be just 23 hours, so the difference you calculate is 1 hour short of being 279 days at you had expected and had observed locally.
java.time
Date and time math is too complicated and error-prone to do yourself the way you tried. You should always leave it to a well-proven library. Here’s the correct and modern solution.
DateTimeFormatter dateFormatter = DateTimeFormatter.ofPattern("d-MM-uuuu");
String sDate = "10-11-2017";
String eDate = "16-08-2018";
LocalDate startDate = LocalDate.parse(sDate, dateFormatter);
LocalDate endDate = LocalDate.parse(eDate, dateFormatter);
long difference = ChronoUnit.DAYS.between(startDate, endDate);
System.out.println(Math.abs(difference));
Output is the expected:
279
Since your date strings haven’t got time of day, there is no reason to use LocalDateTime. LocalDate is the correct class to use. It also makes sure that no number truncation can happen since there is always a whole number of days between two dates.
Question: Will that work on Java 7?
Yes, java.time just requires at least Java 6.
In Java 8 and later and on newer Android devices (from API level 26) the modern API comes built-in.
In Java 6 and 7 get the ThreeTen Backport, the backport of the modern classes (ThreeTen for JSR 310; see the links at the bottom).
On (older) Android use the Android edition of ThreeTen Backport. It’s called ThreeTenABP. And make sure you import the date and time classes from org.threeten.bp with subpackages.
Links
Oracle tutorial: Date Time explaining how to use java.time.
Java Specification Request (JSR) 310, where java.time was first described.
ThreeTen Backport project, the backport of java.time to Java 6 and 7 (ThreeTen for JSR-310).
ThreeTenABP, Android edition of ThreeTen Backport
Question: How to use ThreeTenABP in Android Project, with a very thorough explanation.

SimpleDataFormat uses the JVM's default timezone to create Date objects. In case of daylight saving time, this might result in a +/- 1 day difference between two dates.
You have a couple of options:
Explicitly set the timezone of your SimpleDateFormat objects to GMT/UTC.
Explicitly set the timezone of your JVM to GMT/UTC.
In Java 8, use the new java.time API; in earlier versions of Java use an alternative like Joda Time.

calendar start date before end date on same day difference

I have two calendar dates where i am getting the difference between in days, hours, and minutes.
This works perfectly if the end date is greater than the start date.
What doesnt work is if the start date is the same day of week as the end date, but an earlier time than the end date.
For example: end date 2:20 pm Saturday, and start date is 7:20 pm on saturday.
It calculates it at like 0days, and 5 hours. But, it should be more like 7 days.
Here is the code
long t1 = curCal.getTimeInMillis();
long t2 = setCal.getTimeInMillis();
if(t2 < t1){
days = t1-t2;
}else{
days = t2-t1;
}
long toDays = TimeUnit.MILLISECONDS.toDays(days);
long toHours = TimeUnit.MILLISECONDS.toHours(days) % 24;
long toMinutes = TimeUnit.MILLISECONDS.toMinutes(days) % 60;
String toastMessage = String.format(" %d Days %d Hours %d Minutes", toDays, toHours, toMinutes);
Toast.makeText(context, "ALARM in" + " " + toastMessage , Toast.LENGTH_LONG).show();
How can i handle the case where the end date is the same day as the start date, but the end date is a time before the start date?
Thanks
EDIT
I think i solved my problem. I am adding it for anyone else having the same issue. if end date = startdate(same day) add 7 to the calendar object for enddate. psuedocode
if (enddate == startdate)) {
enddate.add(Calendar.DAY_OF_YEAR, 7);
}

ZoneId zone = ZoneId.of("Europe/Busingen");
DayOfWeek alarmDay = DayOfWeek.SUNDAY;
LocalTime alarmTime = LocalTime.of(14, 20);
ZonedDateTime now = ZonedDateTime.now(zone);
ZonedDateTime alarmDateTime = now.with(alarmDay).with(alarmTime);
if (alarmDateTime.isBefore(now)) {
alarmDateTime = alarmDateTime.plusWeeks(1);
}
Duration difference = Duration.between(now, alarmDateTime);
String toastMessage = String.format(" %d Days %d Hours %d Minutes",
difference.toDaysPart(), difference.toHoursPart(), difference.toMinutesPart());
System.out.println(toastMessage);
Running just now (Sunday 22:03:17 in Büsingen) I got:
6 Days 16 Hours 16 Minutes
I believe that I am contributing the answer that is not only the modern one but also the more robust one.
Modern: The Calendar class is long outdated and by today’s standards poorly designed. Instead I use and recommend java.time, the modern Java date and time API.
Robust: As far as I can tell your code doesn’t only have an issue when today and alarm date are the same day of week, but also if the alarm falls on an earlier day of week. I take that into account.
Furthermore accurate: In cases where you cross transitions to and from summer time (DST), you may get the wrong number of hours when you use the millisecond values in your calculation. Using two ZonedDateTime objects minimizes surprises here. It does require you to fill in your desired time zone where I put Europe/Busingen since summer time transitions are time zone specific.
Furthermore more precisely modelled: Using a Calendar, a date and time, for a weekly recurring alarm seems a bit funny. What you need is a day-of-week and a time of day, so I use that. java.time offers the classes needed, the DayOfWeek enum and the LocalTime class.
I am in fact so modern that I am using the toXxxPart methods of the Duration class that were introduced in Java 9. For formatting the Duration if you are not yet using Java 9 you will need to subtract first the days from the duration to get the hours: use the minusDays method. Then do similarly with minusHours to get the minutes.
long toDays = difference.toDays();
difference = difference.minusDays(toDays);
long toHours = difference.toHours();
difference = difference.minusHours(toHours);
long toMinutes = difference.toMinutes();
Question: Can I use java.time on Android?
Yes, java.time works nicely on older and newer Android devices. It just requires at least Java 6.
In Java 8 and later and on newer Android devices (from API level 26, I’m told) the modern API comes built-in.
In Java 6 and 7 get the ThreeTen Backport, the backport of the new classes (ThreeTen for JSR 310; see the links at the bottom).
On (older) Android use the Android edition of ThreeTen Backport. It’s called ThreeTenABP. And make sure you import the date and time classes from org.threeten.bp with subpackages.
Links
Oracle tutorial: Date Time explaining how to use java.time.
Java Specification Request (JSR) 310, where java.time was first described.
ThreeTen Backport project, the backport of java.timeto Java 6 and 7 (ThreeTen for JSR-310).
ThreeTenABP, Android edition of ThreeTen Backport
Question: How to use ThreeTenABP in Android Project, with a very thorough explanation.

Reading your question another way, if t1 is the start date and t2 is the end date, your logic does not include the case where t1 < t2 and t2 - t1 < 1. In this case, you need to add 7 to the number of days. Something like:
long t1 = curCal.getTimeInMillis();
long t2 = setCal.getTimeInMillis();
if(t2 < t1){
days = t1-t2;
}else{
days = t2-t1;
if (days < 1) {
days += 7;
}
}
All of this can be simplified to
days = Math.abs(t1 - t2);
if (days < 1 && t1 < t2) {
days += 7;
}

Setting Calendar fields in Android

setting the day field in a calendar using
myCalender.set(Calendar.DAY_OF_WEEK, Calendar.FRIDAY);
does is put set the day to the next Friday or the past Friday or maybe the closest?
Also what if I don't set the year or any other field for the calendar, what are the default values?

Neither. Yet. It’s complicated. But don’t use Calendar, see below.
From the documentation of the two-arg set method:
Sets the given calendar field to the given value. The value is not
interpreted by this method…
So during this call it just sets the day-of-week field to Friday. The year, month and day-of-month stay the same, that is, the date isn’t effectively changed. Yet.
If and when the Calendar eventually computes and resolves its fields,
If there is any conflict in calendar field values, Calendar gives
priorities to calendar fields that have been set more recently. The
following are the default combinations of the calendar fields. The
most recent combination, as determined by the most recently set single
field, will be used.
If you have only set the day of week (which will likely have introduced a conflict with the other fields), the following combination applies:
YEAR + MONTH + WEEK_OF_MONTH + DAY_OF_WEEK
So it will pick the Friday in the same week.
What defines a week is determined by the Calendar’s first-day-of-week field. Its initial value is determined by the Calendar’s locale, and you can control it through getFirstDayOfWeek() and setFirstDayOfWeek(). This in turn means that the default behaviour for a Calendar in a European locale previously set to a Sunday will go back to the previous Friday, whereas a Calendar in the US locale would pick the next Friday instead.
If you have also set other fields after setting the day-of-week but before fields are calculated, it is a different story.
Default values?
Generally the default values of Calendar fields are current date and time in your JVM’s time zone (usually, but not always, the same as your device’s time zone).
You don’t need to care
The good news is that you don’t need to care. The Calendar class is long outmoded anyway, and it was also (seen in retrospect) poorly designed, so you should not use it. Instead use java.time, the modern Java date and time API. It is so much nicer to work with. Depending on your need, you may for example use LocalDate for a date or ZonedDateTime for a date and time of day with time zone.
The modern classes offer you a great deal of better clarity and more flexibility. For example:
LocalDate ld = LocalDate.now(ZoneId.of("Pacific/Saipan"));
// the following calls do what the method names say
ld = ld.with(TemporalAdjusters.next(DayOfWeek.FRIDAY));
ld = ld.with(TemporalAdjusters.nextOrSame(DayOfWeek.FRIDAY));
ld = ld.with(TemporalAdjusters.previous(DayOfWeek.FRIDAY));
ld = ld.with(TemporalAdjusters.previousOrSame(DayOfWeek.FRIDAY));
// set to Friday in the same ISO week
ld = ld.with(ChronoField.DAY_OF_WEEK, DayOfWeek.FRIDAY.getValue());
// set to Friday in the same US week
ld = ld.with(WeekFields.SUNDAY_START.dayOfWeek(),
DayOfWeek.FRIDAY.get(WeekFields.SUNDAY_START.dayOfWeek()));
Question: Can I use java.time on Android?
Yes, java.time works nicely on Android devices. It just requires at least Java 6.
In Java 8 and later and on new Android devices (from API level 26, I’m told) the new API comes built-in.
In Java 6 and 7 get the ThreeTen Backport, the backport of the new classes (ThreeTen for JSR 310, where the modern API was first described).
On (older) Android, use the Android edition of ThreeTen Backport. It’s called ThreeTenABP. Make sure you import the date and time classes from package org.threeten.bp and subpackages.
Links
Oracle tutorial: Date Time, explaining how to use java.time.
ThreeTen Backport project
ThreeTenABP, Android edition of ThreeTen Backport
Question: How to use ThreeTenABP in Android Project, with a very thorough explanation.
Java Specification Request (JSR) 310.

Its will be nex Friday
Friday, 23 February 2018 year., 20:44:17.353
Default values is this Year

what are the default values
Calendar rightNow = Calendar.getInstance(); //the default is the current time/date
next Friday or the past Friday or maybe the closest?
next time/date, therefore, the answer is next Friday.
see the documentation

it turns out that using myCalender.set(Calendar.DAY_OF_WEEK, Calendar.FRIDAY)
is a complete mess, it may set the day to next or the past Friday, I have been trying a lot but couldn't figure the logic!
Anyway, all I needed was to set the calendar to a particular day in the next week, and I managed to do this using the answer to that question ..
set the calendar to next Thursday

How to subtract X days from a date using Java calendar?

Anyone know a simple way using Java calendar to subtract X days from a date?
I have not been able to find any function which allows me to directly subtract X days from a date in Java. Can someone point me to the right direction?

Taken from the docs here:
Adds or subtracts the specified amount of time to the given calendar field, based on the calendar's rules. For example, to subtract 5 days from the current time of the calendar, you can achieve it by calling:
Calendar calendar = Calendar.getInstance(); // this would default to now
calendar.add(Calendar.DAY_OF_MONTH, -5).

You could use the add method and pass it a negative number. However, you could also write a simpler method that doesn't use the Calendar class such as the following
public static void addDays(Date d, int days)
{
d.setTime( d.getTime() + (long)days*1000*60*60*24 );
}
This gets the timestamp value of the date (milliseconds since the epoch) and adds the proper number of milliseconds. You could pass a negative integer for the days parameter to do subtraction. This would be simpler than the "proper" calendar solution:
public static void addDays(Date d, int days)
{
Calendar c = Calendar.getInstance();
c.setTime(d);
c.add(Calendar.DATE, days);
d.setTime( c.getTime().getTime() );
}
Note that both of these solutions change the Date object passed as a parameter rather than returning a completely new Date. Either function could be easily changed to do it the other way if desired.

Anson's answer will work fine for the simple case, but if you're going to do any more complex date calculations I'd recommend checking out Joda Time. It will make your life much easier.
FYI in Joda Time you could do
DateTime dt = new DateTime();
DateTime fiveDaysEarlier = dt.minusDays(5);

tl;dr
LocalDate.now().minusDays( 10 )
Better to specify time zone.
LocalDate.now( ZoneId.of( "America/Montreal" ) ).minusDays( 10 )
Details
The old date-time classes bundled with early versions of Java, such as java.util.Date/.Calendar, have proven to be troublesome, confusing, and flawed. Avoid them.
java.time
Java 8 and later supplants those old classes with the new java.time framework. See Tutorial. Defined by JSR 310, inspired by Joda-Time, and extended by theThreeTen-Extra project. The ThreeTen-Backport project back-ports the classes to Java 6 & 7; the ThreeTenABP project to Android.
The Question is vague, not clear if it asks for a date-only or a date-time.
LocalDate
For a date-only, without time-of-day, use the LocalDate class. Note that a time zone in crucial in determining a date such as "today".
LocalDate today = LocalDate.now( ZoneId.of( "America/Montreal" ) );
LocalDate tenDaysAgo = today.minusDays( 10 );
ZonedDateTime
If you meant a date-time, then use the Instant class to get a moment on the timeline in UTC. From there, adjust to a time zone to get a ZonedDateTime object.
Instant now = Instant.now(); // UTC.
ZoneId zoneId = ZoneId.of( "America/Montreal" );
ZonedDateTime zdt = ZonedDateTime.ofInstant( instant , zoneId );
ZonedDateTime tenDaysAgo = zdt.minusDays( 10 );
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.

int x = -1;
Calendar cal = ...;
cal.add(Calendar.DATE, x);
See java.util.Calendar#add(int,int)

Instead of writing my own addDays as suggested by Eli, I would prefer to use DateUtils from Apache. It is handy especially when you have to use it multiple places in your project.
The API says:
addDays(Date date, int amount)
Adds a number of days to a date returning a new object.
Note that it returns a new Date object and does not make changes to the previous one itself.

I faced the same challenge where I needed to go back by 1 day (should be able to roll back by one even if previous day falls into previous year or months).
I did following, basically subtracted by 24 hours for 1 day.
someDateInGregorianCalendar.add(Calendar.HOUR, -24);
Alternatively, I could also do
GregorianCalendar cal = new GregorianCalendar();
cal.set(Calendar.YEAR, 2021);
cal.set(Calendar.MONTH, 0);
cal.set(Calendar.DATE, 1);
System.out.println("Original: " + cal.getTime());
cal.add(Calendar.DATE, -1);
System.out.println("After adding DATE: " + cal.getTime());
OUTPUT:
Original: Fri Jan 01 15:08:33 CET 2021
After adding DATE: Thu Dec 31 15:08:33 CET 2020

It can be done easily by the following
Calendar calendar = Calendar.getInstance();
// from current time
long curTimeInMills = new Date().getTime();
long timeInMills = curTimeInMills - 5 * (24*60*60*1000); // `enter code here`subtract like 5 days
calendar.setTimeInMillis(timeInMills);
System.out.println(calendar.getTime());
// from specific time like (08 05 2015)
calendar.set(Calendar.DAY_OF_MONTH, 8);
calendar.set(Calendar.MONTH, (5-1));
calendar.set(Calendar.YEAR, 2015);
timeInMills = calendar.getTimeInMillis() - 5 * (24*60*60*1000);
calendar.setTimeInMillis(timeInMills);
System.out.println(calendar.getTime());

I believe a clean and nice way to perform subtraction or addition of any time unit (months, days, hours, minutes, seconds, ...) can be achieved using the java.time.Instant class.
Example for subtracting 5 days from the current time and getting the result as Date:
new Date(Instant.now().minus(5, ChronoUnit.DAYS).toEpochMilli());
Another example for subtracting 1 hour and adding 15 minutes:
Date.from(Instant.now().minus(Duration.ofHours(1)).plus(Duration.ofMinutes(15)));
If you need more accuracy, Instance measures up to nanoseconds. Methods manipulating nanosecond part:
minusNano()
plusNano()
getNano()
Also, keep in mind, that Date is not as accurate as Instant. My advice is to stay within the Instant class, when possible.

Someone recommended Joda Time so - I have been using this CalendarDate class http://calendardate.sourceforge.net
It's a somewhat competing project to Joda Time, but much more basic at only 2 classes. It's very handy and worked great for what I needed since I didn't want to use a package bigger than my project. Unlike the Java counterparts, its smallest unit is the day so it is really a date (not having it down to milliseconds or something). Once you create the date, all you do to subtract is something like myDay.addDays(-5) to go back 5 days. You can use it to find the day of the week and things like that.
Another example:
CalendarDate someDay = new CalendarDate(2011, 10, 27);
CalendarDate someLaterDay = today.addDays(77);
And:
//print 4 previous days of the week and today
String dayLabel = "";
CalendarDate today = new CalendarDate(TimeZone.getDefault());
CalendarDateFormat cdf = new CalendarDateFormat("EEE");//day of the week like "Mon"
CalendarDate currDay = today.addDays(-4);
while(!currDay.isAfter(today)) {
dayLabel = cdf.format(currDay);
if (currDay.equals(today))
dayLabel = "Today";//print "Today" instead of the weekday name
System.out.println(dayLabel);
currDay = currDay.addDays(1);//go to next day
}

Eli Courtwright second solution is wrong, it should be:
Calendar c = Calendar.getInstance();
c.setTime(date);
c.add(Calendar.DATE, -days);
date.setTime(c.getTime().getTime());