Develop Reference

Get the First day and the last day of month from an Instant

I have a method using 2 Instants in parameters getIssuesBillable(Instant start, Instant end, ....), my question is how I get the first day of a month and the last day of the month using a Java 8 Instant?
I already tried use withDayOfMonth(), and lengthOfMonth():
LocalDate initial = LocalDate.now();
LocalDate start = initial.withDayOfMonth(firstDayOfMonth());
LocalDate end = initial.withDayOfMonth(lastDayOfMonth());
But in this case, I need to convert and make some workarounds in this case, if someone knows a better way to do it I really appreciate any response.

tl;dr
Use modern java.time classes.
Here is a brief nonsensical example of starting with an Instant (a moment in UTC), assigning a time zone to view that moment through the wall-clock time used by the people of a particular region (a time zone), extracting the year-and-month as perceived in that time zone, and determining the first and last day of that month, rendering LocalDate objects.
YearMonth // Represent a year-and-month, the entire month as a whole.
.from( // Determine the year-and-month of some other date-time object.
Instant // Represent a moment in UTC.
.now() // Capture the current moment in UTC.
.atZone( // Adjust from UTC to a particular time zone.
ZoneId.of( "Pacific/Auckland" )
) // Returns a `ZonedDateTime` object.
) // Returns a `YearMonth` object.
.atDay( 1 ) // Returns a `LocalDate` object.
…or
…
.atEndOfMonth() // Returns a `LocalDate` object.
By the way, a realistic version of that particular code would be: YearMonth.now( ZoneId.of( "Pacific/Auckland" ) ).atDay( 1 )
Moment versus date-only
Instant is a moment in UTC, a date with time-of-day and an offset-from-UTC of zero.
A LocalDate is a date-only value, without time-of-day and without time zone.
You need to specify the time zone by which you want to perceive the date, the wall-clock time used by the people of a particular region.
A time zone is crucial in determining a date. For any given moment, the date varies around the globe by zone. For example, a few minutes after midnight in Paris France is a new day while still “yesterday” in Montréal Québec.
If no time zone is specified, the JVM implicitly applies its current default time zone. That default may change at any moment during runtime(!), so your results may vary. Better to specify your desired/expected time zone explicitly as an argument.
Specify a proper time zone name in the format of continent/region, such as America/Montreal, Africa/Casablanca, or Pacific/Auckland. Never use the 3-4 letter abbreviation such as EST or IST as they are not true time zones, not standardized, and not even unique(!).
ZoneId z = ZoneId.of( "Africa/Casablanca" ) ;
ZonedDateTime zdt = instant.atZone( z ) ;
Extract the date-only.
LocalDate ld = zdt.toLocalDate() ;
From there, proceed with your other code.
Or work with the month as a whole, using YearMonth class.
YearMonth ym = YearMonth.from( zdt ) ;
LocalDate first = ym.atDay( 1 ) ;
LocalDate last = ym.atEndOfMonth() ;
Tip: You might find helpful the LocalDateRange and Interval classes in the ThreeTen-Extra library.
Tip: Learn about the Half-Open approach to define a span of time, where the beginning is inclusive while the ending is exclusive. So a month starts on the first and runs up to, but does not include, the first day of the following month.
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, Java SE 11, and later - 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
Most 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.

For the first day of the month, depends on the time zone:
YearMonth.from(Instant.now().atZone(ZoneId.of("UTC"))).atDay(1);
For the last day of the month, depends on the time zone:
YearMonth.from(Instant.now().atZone(ZoneId.of("UTC"))).atEndOfMonth();

Java Convert UTC Date to local Date with Joda

This code is working, but I want to use Joda-Time
public static Date dateFromUTC(Date date){
return new Date(date.getTime() + Calendar.getInstance().getTimeZone().getOffset(date.getTime()));
}
I tried this, but it's not working - what's the problem with this?
public static Date dateFromUTC(Date date){
return new DateTime(date).withZone(DateTimeZone.getDefault()).toDate();
}

tl;dr
Use java.time classes instead.
Instant.now() // Capture current moment in UTC. Always in UTC, by definition.
…and…
ZonedDateTime.now() // Capture current moment as seen through the wall-clock time of the people in the region of the time zone used by default in this JVM.
Details
As others said, you misunderstood the concepts involved in these classes. A java.util.Date represents a moment in UTC, always in UTC†, never in some other time zone. So the code seen in the Question is non-sensical. You are working too hard!
java.time
The Joda-Time project is now in maintenance mode, with the team advising migration to the java.time classes. Many of the concepts are similar between Joda-Time and java.time as both projects are led by the same man, Stephen Colebourne.
When you are ready to migrate, use Instant in place of java.util.Date.
Instant instant = Instant.now() ; // Capture the current moment in UTC.
instant.toString(): 2018-01-23T12:34:56.123456789Z
Instead of java.util.Calendar, use ZonedDateTime to represent a moment seen through the wall-clock time of a particular region (a time zone).
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( "Pacific/Auckland" ) ;
ZonedDateTime zdt = instant.atZone( z ) ; // Same moment, same point on the timeline, different wall-clock time.
As a shortcut, you can skip the Instant if you want only the zoned time.
ZoneId z = ZoneId.of( "Africa/Tunis" ) ;
ZonedDateTime zdt = ZonedDateTime.now( z ) ; // Capture the current moment as seen by people in a certain time zone.
You can get to UTC from there by extracting an Instant object.
Instant instant = zdt.toInstant() ; // Same moment, same point on the timeline, but viewed with the wall-clock time of UTC.
† Actually, there is a time zone assigned deep within a java.util.Date but is irrelevant to our discussion here. Confusing? Yes. One of many reasons to avoid the awful mess that is the old Date/Calendar and related legacy date-time classes.
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:
new DateTime(date, DateTimeZone.UTC)
.toLocalDateTime() // value without timezone
.toDateTime() // convert to default timezone
.toDate();
Your code actually does nothing to the date, because new DateTime(date) creates a DateTime object with default timezone. And then you just convert it back to java.util.Date.

First of all, read the article linked in the comments: https://codeblog.jonskeet.uk/2017/04/23/all-about-java-util-date/
A java.util.Date doesn't have a timezone. It actually represents a point in time: the number of milliseconds since unix epoch (Jan 1st 1970, at midnight, in UTC).
When you print the Date, though, it uses the JVM default timezone to convert the Date to date/time values, but the Date itself doesn't have a timezone.
That's why converting a Date object to another timezone doesn't make sense.
If you want to know the date (day, month, year) and time (hour, minute, second, millisecond) that corresponds to the Date in a specific timezone, then you can use Joda-Time:
// java.util.Date
Date date = new Date();
// the Date converted to UTC
DateTime utc = new DateTime(date, DateTimeZone.UTC);
// the Date converted to JVM default timezone
DateTime convertedToDefaultTz= new DateTime(date, DateTimeZone.getDefault());
The conversion can also be made using another DateTime:
DateTime convertedToDefaultTz = utc.withZone(DateTimeZone.getDefault());
Joda's DateTime has a timezone attached to it, so now it makes sense to convert to another one. But the Date objects returned by it will always be the same, because all of them represent the same instant (the same point in the timeline):
Date d1 = utc.toDate();
Date d2 = convertedToDefaultTz.toDate();
System.out.println(d1.equals(d2)); // true
All because - again - a Date doesn't have a timezone.

Java Converting String to Date resulting one day less even though browser time zone provided

I'm sending date from the Angular app as String to server and converting to java Date object to store in the database.
Also sending timeZoneOffset from UI to use the client's time zone while converting. (After googling I found this approach to get the proper result based on the user location)
Written the following code to convert:
public static void main(String args[]) throws ParseException {
String inputDate = "04/05/2018"; // This date coming from UI
int timeZoneOffset = -330; // This offset coming from UI
// (new Date().getTimeZoneOffset())
getDate(inputDate, timeZoneOffset);
}
public static Date getDate(String inputDate, int timeZoneOffset)
throws ParseException {
SimpleDateFormat dateFormat = new SimpleDateFormat("MM/dd/yyyy");
ZoneOffset zoneOffset = ZoneOffset.ofTotalSeconds(-timeZoneOffset * 60);
System.out.println("Default time zone: " + TimeZone.getDefault().getID());
TimeZone timeZone = TimeZone.getTimeZone(zoneOffset);
System.out.println("Time zone from offset: " + timeZone.getID());
dateFormat.setTimeZone(timeZone);
Date date = dateFormat.parse(inputDate);
System.out.println("Converted date: " + date);
return date;
}
Expected output:
Default time zone: America/New_York
Time zone from offset: GMT+05:30
Converted date: Thu April 5 00:00:00 IST 2018
Actual result in server:
Default time zone: America/New_York
Time zone from offset: GMT+05:30
Converted date: Wed April 4 14:30:00 EDT 2018
Why is the date decreasing to one day even I set the users time zone? I'm new to Date and Time related concepts and I googled a couple of times didn't find answer, could someone please help on this.
Thanks in advance

The Answer by Godfrey is correct.
tl;dr
LocalDate.parse(
"04/05/2018" ,
DateTimeFormatter.ofPattern( "MM/dd/uuuu" )
)
.atStartOfDay(
ZoneId.of( "Asia/Kolkata" )
)
.toString()
2018-04-05T00:00+05:30[Asia/Kolkata]
For storage in your database, use UTC.
When a new day starts in India, the date at UTC is still “yesterday”, so April 4th rather than April 5th. Same moment, same point on the timeline, different wall-clock time.
LocalDate.parse(
"04/05/2018" ,
DateTimeFormatter.ofPattern( "MM/dd/uuuu" )
)
.atStartOfDay(
ZoneId.of( "Asia/Kolkata" )
)
.toInstant()
2018-04-04T18:30:00Z
java.time
You are using terrible old date-time classes that have proven to be poorly designed, confusing, and troublesome. They are now supplanted by the java.time classes.
Avoid legacy date-time classes entirely
ZoneOffset zoneOffset = ZoneOffset.ofTotalSeconds(-timeZoneOffset * 60);
…
TimeZone timeZone = TimeZone.getTimeZone(zoneOffset);
You are mixing the modern classes (ZoneOffset) with the troublesome legacy classes (TimeZone). Do not mix the modern classes with the legacy classes. Forget all about the old classes including Date, Calendar, and SimpleDateFormat. The java.time classes are designed to entirely supplant the legacy classes.
Instead of TimeZone, use ZoneId (and ZoneOffset).
LocalDate
Parse your input string as a LocalDate. The LocalDate class represents a date-only value without time-of-day and without time zone.
String input = "04/05/2018" ;
DateTimeFormatter f = DateTimeFormatter.ofPattern( "MM/dd/uuuu" ) ;
LocalDate ld = LocalDate.parse( input , f ) ;
Offset versus Time Zone
int timeZoneOffset = -330;
An offset-from-UTC is not a time zone. An offset is simply a number of hours, minutes, and seconds of displacement from UTC. Your choice of variable name indicates possible confusion on this point.
ZoneOffset offset = ZoneOffset.of( -3 , 30 ) ;
A time zone is a history of past, present, and future changes in offset used by the people of a particular region. So a time zone is always preferable to an offset.
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( "Asia/Kolkata" ) ; // India time zone. Currently uses offset of +05:30 (five and a half hours ahead of UTC).
First moment of the day
You seem to be aiming for the first moment of that date in that zone. Let java.time determine that first-moment-of-the-day. Do not assume that time is 00:00:00. In some zones on some dates, the day may start at another time such as 01:00:00.
ZonedDateTime zdt = ld.atStartOfDay( z ) ; // Determine the first moment of the day on this date in this zone. Not always 00:00:00.
As an example of why you should be using time zones rather than mere offset-from-UTC, look at your example data of -330 which I might easily misinterpret to be three and a half hours behind UTC. This offset is currently only used in the zone America/St_Johns, and only used there for part of the year. So if you applied an offset of -03:30 to a date in the wrong part of the year, your results would be invalid yet go undetected.
Using offset (not recommended)
But your example lacks time zone, so let’s go with offset-from-UTC rather than zone.
Your use of an int integer number to represent an offset-from-UTC is a poor choice of types. First of all, it is ambiguous. That -330 might be interpreted to be a clumsy attempt at -03:30 offset of three and a half hours behind schedule. Secondly, it makes parsing trickier than need be. Thirdly, as a number of minutes, it ignores the possibility of an offset with seconds. Fourthly, you use a negative number for an offset ahead of UTC (apparently) despite common usage and standard usage being the opposite. Lastly, it ignores the clear standard set by ISO 8601 for representing offsets as text: ±HH:MM:SS (and variations). By the way, the padding zero is optional in the standard, but I recommend always including because various libraries and protocols expect it.
Your intent appears to be a number of minutes intended by the integer number.
long seconds =( TimeUnit.MINUTES.toSeconds( - 330 ) * -1 ); // Multiply by negative one to flip the sign to standard ISO 8601 usage, where `+` means “ahead* of UTC and `-` means *behind* UTC.
seconds: 19800
ZoneOffset offset = ZoneOffset.ofTotalSeconds( ( int ) seconds );
offset.toString(): +05:30
Last step: get the first moment of the day in this offset. Caveat: We do not know for certain if this offset is valid on this date, as we lack a time zone.
Convert from the returned ZonedDateTime to an OffsetDateTime. As discussed above, determining first moment of day should always be done with a time zone, and thereby get a ZonedDateTime. We are violating that sensible practice to use an offset, but using the returned ZonedDateTime object would be misleading as ours would lack a true time zone, and have only a mere offset. So the OffsetDateTime class makes our intentions clear and our code more self-documenting.
OffsetDateTime odt = ld.atStartOfDay( offset ).toOffsetDateTime();
Again, this approach using offset is not recommending, as you should be instead gathering a time zone name from the user as input rather than an offset.
UTC
Generally best to store moments in UTC.
Extract a Instant from your OffsetDateTime or ZonedDateTime to get the same moment as UTC.
Instant instant = zdt.toInstant() ;
2018-04-04T18:30:00Z
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, 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.

It's not decreasing by one day, it is decreasing by 11.5 hours. That happens to be the time difference between GMT+05:30 and "America/New_York", which is GMT-04:30 or GMT-05:30 (depending on time of year).
GMT+05:30 is somewhere in India, I think, since that is about the only place to use a 30 minute offset rather than a whole hour. When it is April 5th in India, it is still April 4th in New York.
The problem may be you aren't getting a time from the client, so it will assume midnight. If you are doing time zone conversion, it is best to include the actual time.

java: timezone getTimeZone("GMT-0700")' timezone useDaylight incorrect

I want to get the time zone information for Los Angeles, now 10/10/2017 is daylight saving time,
But I got a different result when I got the time zone in Los Angeles in two ways.
public class TimeZoneDemo2 {
public static void main(String[] args) {
TimeZone timeZoneLosAngeles =
TimeZone.getTimeZone("America/Los_Angeles");
System.out.println(timeZoneLosAngeles);
TimeZone timeZoneGmtMinus07 = TimeZone.getTimeZone("GMT-07:00");
System.out.println(timeZoneGmtMinus07);
}
}
the result is:
sun.util.calendar.ZoneInfo[id="America/Los_Angeles",offset=-28800000,dstSavings=3600000,useDaylight=true,transitions=185,lastRule=java.util.SimpleTimeZone[id=America/Los_Angeles,offset=-28800000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]]
sun.util.calendar.ZoneInfo[id="GMT-07:00",offset=-25200000,dstSavings=0,useDaylight=false,transitions=0,lastRule=null]
My question is: Information about daylight saving time in time zone information obtained by "America/Los_Angeles". Why not include daylight saving time information (useDaylight = false) in the time zone information obtained by "GMT -0700"?

I want to get the time zone information for Los Angeles, now 10/10/2017 is daylight saving time
So you should ask for the "America/Los_Angeles" zone. That's what it's there for.
The "GMT-07:00" zone is a fixed-offset zone - it's only suitable when you want to represent "a time zone which is permanently seven hours behind UTC". That doesn't apply to Los Angeles.
There are plenty of other time zones which are sometimes at UTC-7 - why would you expect GMT-07:00 to mean "the time zone observed in Los Angeles"?
In other words, Java is doing the right thing - it's your expectations of what the "GMT-07:00" zone means that are incorrect.

The Answer by Jon Skeet is correct and should be accepted. You cannot reliably determine a time zone from an offset-from-UTC as many zones may share an offset coincidentally. Also, the offset for a zone likely varies over time.
Here are some code samples addressing the issue using more modern classes than that seen in the Question.
java.time
You are using troublesome old date-time classes that are now legacy, supplanted by the java.time classes.
As others stated, if you know the intended time zone, always use that zone in preference to a mere offset-from-UTC. An offset is simply a number of hours, minutes, and seconds ahead of, or behind, UTC. A time zone is a history of changes to the offset used by the people of a region. A time zone knows the past, present, and (tentatively) the future of such changes in offset.
The ZoneId and ZoneOffset classes replace TimeZone.
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/Los_Angeles" ) ; // Or "Africa/Tunis", "Pacific/Auckland", etc.
Get the current moment as seen through the lens of that zone.
ZonedDateTime zdt = ZonedDateTime.now( z ) ; // Fetch current moment for that zone.
Extract that same moment but adjusted into UTC.
Instant instant = zdt.toInstant() ; // Extract the same moment but in UTC.
Adjust that some moment into another zone.
ZonedDateTime zdtKolkata = instant.atZone( ZoneId.of( "Asia/Kolkata" ) ) ; // Determine same moment, same point on timeline, but in another time zone.
All three of these objects represent the very same simultaneous point on the timeline, but viewed with a different wall-clock time.
See the offset used by the people of that region at that moment.
ZoneOffset offset = z.getRules().getOffset( instant ) ; // Get the offset in place at that moment for that time zone.
You will find that for 2018, in part of that year the offset for America/Los_Angeles will be -07:00 (sever hours behind UTC). In the other part of the year, the offset will be -08:00 (eight hours behind UTC). This change in offset is due to politicians’ decision to observe Daylight Saving Time (DST).
About java.time
The java.time framework is built into Java 8 and later. These classes supplant the troublesome old legacy date-time classes such as java.util.Date, Calendar, & SimpleDateFormat.
The Joda-Time project, now in maintenance mode, advises migration to the java.time classes.
To learn more, see the Oracle Tutorial. And search Stack Overflow for many examples and explanations. Specification is JSR 310.
Where to obtain the java.time classes?
Java SE 8, Java SE 9, and later
Built-in.
Part of the standard Java API with a bundled implementation.
Java 9 adds some minor features and fixes.
Java SE 6 and Java SE 7
Much of the java.time functionality is back-ported to Java 6 & 7 in ThreeTen-Backport.
Android
Later versions of Android bundle implementations of the java.time classes.
For earlier Android, the ThreeTenABP project adapts ThreeTen-Backport (mentioned above). See How to use ThreeTenABP….
The ThreeTen-Extra project extends java.time with additional classes. This project is a proving ground for possible future additions to java.time. You may find some useful classes here such as Interval, YearWeek, YearQuarter, and more.

android adding or removing hour from timestamp in database

I want to subtract a few days from my timestamp in Android.
I have an SQLite database with a date field of the type long.
When I execute a query where I say date = date - (3 * 86400000) I sometimes experience a one hour difference as a result when converting it to a readable date.
But how is this possible? Has it to do with the daylight savings of one hour in my timezone?
Because I would find it strange if that's the reason because you are doing calculations with two long values and after converting them back to datetime there shouldn't be a daylight saving issue?

Thanks for the replies but I found a solution.
It seems that when you add days in milliseconds to your timestamp and there is an hour difference in daylight settings in between, the date is automatically corrected.
When I do the following, the hour is ignored:
Date d = new Date();
d.setDays(d.getDays() - 2);
However, I would recommend using the Joda library because it's mush more flexible and easy to work with.

tl;dr
Use modern java.time classes.
If you meant 3 days as in calendar dates, do this:
Instant // Represent a moment in UTC with a resolution of nanoseconds.
.ofEpochSecond( x ) // Parse some number of whole seconds or milliseconds from the epoch reference of first moment of 1970 in UTC.
.atZone( // Adjust from UTC to the wall-clock time used by the people of a particular region (a time zone).
ZoneId.of( "Pacific/Auckland" ) // Assign the time zone by which you want the context of their calendar for adding dates.
) // Returns a `ZonedDateTime` object.
.plus( // Move to another moment by adding a span-of-time.
Period.ofDays( 3 ) // Define a span of time as a number of days on the calendar (date) without regard for the length of a day.
) // Returns another `ZonedDateTime` object.
.toInstant() // Adjust from a time zone to UTC. Same moment, different wall-clock time.
.toEpochSeconds() // or maybe `toEpochMillis` depending on your practice with your `long` number.
Write your SQL as:
SELECT * FROM event_ WHERE when_ >= ? ; -- Find events occurring later than the passed moment.
In Java with JDBC 4.2 or later:
myPreparedStatement.setObject( 1 , secondsSinceEpoch ) ; // Pass seconds calculated above.
Retrieval.
OffsetDateTime odt = myResultSet.getObject( … , OffsetDateTime.class ) ;
Count-from-epoch
Your number of type long is presumably a count of whole seconds or milliseconds since an epoch reference date.
If your chosen epoch happens to be that used by “Unix time”, the first moment of 1970 in UTC, 1970-01-01T00:00:00Z, then we can parse in Java as an Instant. An Instant is a moment on the timeline in UTC with a resolution of nanoseconds. An Instant internally is a pair of numbers: a count of whole seconds since epoch, plus a fraction of a second as a count of nanoseconds.
Instant instant = Instant.ofEpochMilli( x ) ;
…or:
Instant instant = Instant.ofEpochSecond( x ) ;
A day is not 24 hours
A day, as in a date on the calendar, is not the same thing as 24 hours. Anomalies in the way politicians define time zones such as Daylight Saving Time (DST) means a day might be 23, 23.5, 24, 25, or some other number of hours-minutes-seconds.
Duration
If you want to add chunks of 24-hours, use Duration.
Duration d = Duration.ofDays( 3 ) ; // `Duration` defines a “day” as being a 24-hours without regard for the calendar dates.
Or specify in hours, which has the same result in Duration class but would be more clear as to your intent and understanding.
Duration d = Duration.ofHours( 3 * 24 ) ; // Same effect as the `Duration.ofDays( 3 )` seen above.
Add to your Instant.
Instant instantLater = instant.plus( d ) ;
Period
If you meant a day as incrementing a day on the calendar, use Period class. This class represents a number of years-months-days.
Period p = Period.ofDays( 3 ) ; // `Period` defines a day as a date on the calendar without regard for its length in hours.
We cannot add that to Instant without regard for time zone issues. If added to an Instant which is always in UTC we would be using the calendar of UTC. For example, adding a day to a value in UTC might translate to “tomorrow” in India while still being “yesterday” in Québec. A time zone is crucial in determining a date. For any given moment, the date varies around the globe by zone.
If no time zone is specified, the JVM implicitly applies its current default time zone. That default may change at any moment during runtime(!), so your results may vary. Better to specify your desired/expected time zone explicitly as an argument.
Specify a proper time zone name in the format of continent/region, such as America/Montreal, Africa/Casablanca, or Pacific/Auckland. Never use the 2-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" ) ;
If you want to use the JVM’s current default time zone, ask for it and pass as an argument. If omitted, the JVM’s current default is applied implicitly. Better to be explicit, as the default may be changed at any moment during runtime by any code in any thread of any app within the JVM.
Apply your ZoneId to the Instant to get a ZonedDateTime.
ZonedDateTime zdt = instant.atZone( z ) ;
Now you can add days to the ZonedDateTime and the calendar used by the people of that region will be taken into account.
ZonedDateTime zdtLater = zdt.plus( p ) ; // By “later” we assume the number of days in the `Period` is positive. Alternatively, a `Period` could go backwards in time with a negative number of days.
To adjust back to UTC, extract a Instant. We still have the same moment, the same point on the timeline, but with a different wall-clock time.
Instant instantLater = zdtLater.toInstant() ; // Same moment, different wall-clock time.
The elapsed time between zdt and zdtLater may or may not be ( 3 * 24 ) hours. If a DST cutover occurred during that time, the number of hours would be either ( ( 3 * 24 ) - 1 ) in the “Spring Ahead” early in the year, or ( ( 3 * 24 ) + 1 ) in the “Fall Back” of the autumn.
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, Java SE 11, and later - 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
Most 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.