Develop Reference

Issue with parsing date time using ZonedDateTime and DateTimeFormatter

I am having two different results from these two blocks even though the input date/time to parse is the same
public class DateTimeFormatterUtilsTest
{
private static final String ISO_DATETIME_PATTERN = "yyyy-MM-dd'T'HH:mm:ss.SSS'Z'";;
private static final String ISO_DATETIME_TO_PARSE = "2007-12-03T10:15:30.000Z";
private static final long TARGET_EPOCH_TIME = 1196676930000L;
#Test
public void testDateTimeFormatterUtils()
{
ZoneId targetZoneid = TimeUtils.getZoneId(TIMEZONE.PST);
DateTimeFormatter formatter = DateTimeFormatter.ISO_INSTANT.withZone(targetZoneid);
long epochTime = parseDateTime(ISO_DATETIME_TO_PARSE, formatter);
assertTrue(epochTime == TARGET_EPOCH_TIME);
// specify custom pattern
DateTimeFormatter formatter1 = DateTimeFormatter.ofPattern(ISO_DATETIME_PATTERN).withZone(targetZoneid);
epochTime = parseDateTime(ISO_DATETIME_TO_PARSE, formatter1);
assertTrue(epochTime == TARGET_EPOCH_TIME);
}
public long parseDateTime(final String dateTimeString, DateTimeFormatter formatter)
{
ZonedDateTime zonedDateTime = ZonedDateTime.parse(dateTimeString, formatter);
System.out.println("parsed zoned date time" + zonedDateTime);
Instant instant = zonedDateTime.toInstant();
long epochTime = instant.toEpochMilli();
System.out.println("Epoch time for" + ISO_DATETIME_TO_PARSE + "is " + epochTime);
return epochTime;
}
}
When I am using DateTimeFormatter.ISO_INSTANT I get the correct epoch time which is 1196676930000, however, when I am usin the .ofPattern method to create the DateTimeFormatter I am getting 1196705730000. Not sure why?
As you can see, the difference is 28 800 000 milliseconds or exactly 8 hours.

Never put quote marks around the Z in a date-time formatting pattern.
Z means +00:00
The Z is a standard abbreviation for an offset of zero. Pronounced “Zulu” per aviation/military convention.
Yuor quotes treat the Z as meaningless string literal, preventing semantic interpretation. The Z carries vital information, meaning “an offset from UTC of zero hours-minutes-seconds”. But your 'Z' parsing pattern ignores that info.
This:
"yyyy-MM-dd'T'HH:mm:ss.SSS'Z'"
… should be:
"yyyy-MM-dd'T'HH:mm:ss.SSSZ"
By ignoring that offset, the JVM’s current default time zone is applied implicitly when you parsed as a ZonedDateTime. Hence your correct but unexpected results.
Instant, not ZonedDateTime
Your input has no indication of time zone. So ZonedDateTime is not called for here.
Instead, parse as an Instant.
Instant.parse( "2007-12-03T10:15:30.000Z" )
If you want to see that moment through the lens of a particular time zone, apply a ZoneId to get a ZonedDateTime. Same moment, different wall-clock time.
ZoneId z = ZoneId.of( "America/New_York" ) ;
ZonedDateTime zdt = instant.atZone( z ) ;
Terminology
Quick review of terms:
UTC is the temporal prime meridian. In the old days this was the time kept at the Royal Observatory in Greenwich, London.
An offset is merely a number of hours-minutes-seconds ahead or behind UTC.
A time zone is a named history of the past, present, and future changes to the offset used by the people of a particular region as decided by their politicians.

How to convert Java LocalDate to milliseconds

I am trying to convert a date formatted in yyyy-mm-dd to LocalDate to milliseconds with this code.
LocalDate.parse("2022-08-01", DateTimeFormatter.ofPattern("yyyy-MM-dd"))
.atStartOfDay(ZoneId.systemDefault()).toInstant().toEpochMilli()
It returns 1659283200000 which is not correct and behind 1 day. Is there better solution for this? The expected value is 1659312000000 in UTC.

Your code is correct, if you want a count of milliseconds since the epoch reference of first moment of 1970 as seen with an offset of zero hours-minutes-seconds from UTC, 1970-01-01T00:00Z.
By the way, no need to specify a formatting pattern. Your input text complies with the ISO 8601 standard used by default in the java.time classes for parsing/generating text.
long millis =
LocalDate
.parse(
"2022-08-01"
)
.atStartOfDay(
ZoneId.systemDefault()
)
.toInstant()
.toEpochMilli()
;
Time Zone
I imagine the problem with getting an unexpected result is the time zone. Your results will vary by time zone.
Understand that the day starts earlier in the east. At any moment, it can be “tomorrow” in Tokyo Japan 🇯🇵 while still “yesterday” in Edmonton Alberta Canada 🇨🇦 .
(photo: NASA)
👉 To avoid surprises, specify your desired/expected time zone explicitly rather than relying on the JVM’s current default time zone.
Example
Same date used in examples below, for two time zones and one offset.
String input = "2022-08-01" ;
Tokyo
ZoneId zoneIdTokyo = ZoneId.of( "Asia/Tokyo" ) ;
long millisTokyo =
LocalDate
.parse(
input
)
.atStartOfDay(
zoneIdTokyo
)
.toInstant()
.toEpochMilli()
;
Edmonton
ZoneId zoneIdEdmonton = ZoneId.of( "America/Edmonton" ) ;
long millisEdmonton =
LocalDate
.parse(
input
)
.atStartOfDay(
zoneIdEdmonton
)
.toInstant()
.toEpochMilli()
;
UTC (offset of zero)
ZoneOffset offsetUtc = ZoneOffset.UTC ;
long millisUtc =
LocalDate
.parse(
input
)
.atStartOfDay(
offsetUtc
)
.toInstant()
.toEpochMilli()
;
Dump to console.
System.out.println( "Tokyo: " + millisTokyo ) ;
System.out.println( "Edmonton: " + millisEdmonton ) ;
System.out.println( "UTC: " + millisUtc ) ;
See this code run live at Ideone.com.
Tokyo: 1659279600000
Edmonton: 1659333600000
UTC: 1659312000000
Interval
You said:
The input date String should represent the current date and past 30 days which should be based on user's timezone. Example is 2022-07-08 to 2022-08-08
I suggest adding the ThreeTen-Extra library to your project. Doing so gives you access to the Interval class to represent a span of time as a pair of Instant objects.
Interval intervalOfPrior30DaysInUtc ( LocalDate end ) {
return
Interval
.of(
end.minusDays( 30 ).atStartOfDay( ZoneOffset.UTC ).toInstant() ,
end.atStartOfDay( ZoneOffset.UTC ).toInstant()
)
;
}

How can I get UTC Instant of startDate and endDate of today in a specific time zone ("Europe/Paris")

I want to get the UTC instant (since my DB is storing in UTC) from Java (which is also in UTC) of a particular time zone, this is what I have tried so far:
public static Instant getStartOfTheDayDateTime(Instant instant, String zoneId) {
ZonedDateTime zoned = instant.atZone(ZONE_ID_TO_ZONE_MAP.get(zoneId));
ZoneId zone = ZoneId.of(zoneId);
return zoned.toLocalDate().atStartOfDay(zone).toInstant();
// ZonedDateTime startOfTheDay = zoned.withHour(0)
// .withMinute(0)
// .withSecond(0)
// .withNano(0);
//
// return startOfTheDay.toInstant();
}
public static Instant getEndOfTheDayDateTime(Instant instant, String zoneId) {
ZonedDateTime zoned = instant.atZone(ZONE_ID_TO_ZONE_MAP.get(zoneId));
ZonedDateTime endOfTheDay = zoned.withHour(0)
.withMinute(0)
.withSecond(0)
.withNano(0)
.plusDays(1);
return endOfTheDay.toInstant();
}
Every attempt shows:
2020-04-10 22:00:00.0(Timestamp), 2020-04-11 22:00:00.0(Timestamp)
Is this the start/end of the day UTC time in Europe/Paris zone ?
I was expecting to have 2020-04-11 02:00:00.0(Timestamp), 2020-04-12 02:00:00.0(Timestamp)

Right now, Paris is on summer time: UTC+2. Paris is 'ahead' of UTC by 2 hours.
So 00:00:00 in Paris local time is 22:00:00 UTC.

Is this the start/end of the day UTC time in Europe/Paris zone ?
Yes. Europe/Paris is in daylight savings time. Midnight in Paris occurred at 22:00 UTC time.
I was expecting to have 2020-04-11 02:00:00.0(Timestamp), 2020-04-12 02:00:00.0(Timestamp)
That's not right, 02:00 UTC would have been 04:00 in Paris time.

Ask programmatically if a moment is in DST
Is this the start/end of the day UTC time in Europe/Paris zone ?
Get start of day.
ZoneId z = ZoneId.of( "Europe/Paris" );
ZonedDateTime zdtStartOfDay = instant.atZone( z ).toLocalDate().atStartOfDay( z ) ;
Ask if that moment is in DST for that zone.
ZoneRules rules = z.getRules();
boolean isDst = rules.isDaylightSavings( zdtStartOfDay.toInstant() );
Pass date-time objects rather than mere strings
public static Instant getStartOfTheDayDateTime(Instant instant, String zoneId)
I suggest you ask the calling programmer to pass a valid ZoneId object rather than a mere string. It should not be the job of this method to validate their string input. If it is reasonable to expect a Instant then it is also reasonable to expect a ZoneId.
public static Instant getStartOfTheDayDateTime(Instant instant, ZoneID zoneId )
Half-Open
public static Instant getEndOfTheDayDateTime(Instant instant, String zoneId) {
Trying to determine the last moment of the day is impossible because of infinitely divisible last second.
Also this approach to defining a span of time is awkward. It makes abutting multiple spans tricky. Various software systems and protocols differ in their resolution of that last fractional second, using milliseconds, microseconds, nanoseconds, or some other fraction.
The common practice in date-time handling is to track a span of time using the Half-Open approach. In Half-Open, the beginning is inclusive while the ending is exclusive.
So a full day begins with the first moment of the day and runs up to, but does not include, the first moment of the next day.
ZoneId z = ZoneId.of( "Europe/Paris" );
ZonedDateTime zdtStartOfDay = instant.atZone( z ).toLocalDate().atStartOfDay( z ) ;
ZonedDateTime zdtStartOfNextDay = instant.atZone( z ).toLocalDate().plusDays( 1 ).atStartOfDay( z ) ;
You might want to break that code out to more lines, for easier reading/debugging.
Instant instant = Instant.now() ; // Or passed in.
ZoneId z = ZoneId.of( "Europe/Paris" ) ;
ZonedDateTime zdt = instant.atZone( z ) ;
LocalDate ld = zdt.toLocalDate() ;
LocalDate ldNextDay = ld.plusDays( 1 ) ;
ZonedDateTime zdtStartOfNextDay = ldNextDay.atStartOfDay( z ) ;
See this code run live at IdeOne.com. For example:
System.out.println( instant ) ; // 2020-04-13T00:15:25.235341Z
System.out.println( zdt ) ; // 2020-04-13T02:15:25.235341+02:00[Europe/Paris]
System.out.println( ld ) ; // 2020-04-13
System.out.println( ldNextDay ) ; // 2020-04-14
System.out.println( zdtStartOfNextDay ) ; // 2020-04-14T00:00+02:00[Europe/Paris]
ThreeTen-Extra Interval
If you do this kind of work with spans of time often, then I suggest adding the ThreeTen-Extra library to your project. That library includes the Interval class to track a span-of-time as a a pair of Instant objects.
Interval interval = Interval.of( zdtStartOfDay.toInstant() , zdtStartOfNextDay.toInstant() ) ;
You can then make use the several handy comparison methods such as abuts, contains, encloses, intersection, overlaps, and union.
Timestamp
Never use the java.sql.Timestamp class. This class is part of the terrible date-time classes that shipped with the earliest versions of Java. These classes are now legacy, supplanted entirely by the modern java.time classes defined in JSR 310 and built into Java 8 and later.
As of JDBC 4.2 we can exchange java.time objects with a database. Use getObject and setObject and updateObject.
The JDBC spec oddly requires support for OffsetDateTime but not the more commonly used Instant and ZonedDateTime. Your particular driver may support these other types. If not, convert.
Retrieval from database.
OffsetDateTime odt = myResultSet.getObject( … , OffsetDateTime.class ) ;
Instant instant = odt.toInstant() ;
Sending to the database.
OffsetDateTime odt = instant.atOffset( ZoneOffset.UTC ) ;
myPreparedStatement.setObject( … , odt ) ;

Generating reports for different time zones in Java

as a part of my requirement,I have to fire a SQL query which takes yesterday's midnight and today's midnight in the respective time zone as input.Is there a way to achieve this?

Use ZonedDateTime:
String DATE_FORMAT = "dd-M-yyyy hh:mm:ss a";
String dateInString = "22-1-2015 10:15:55 AM";
LocalDateTime ldt = LocalDateTime.parse(dateInString, DateTimeFormatter.ofPattern(DATE_FORMAT));
ZoneId singaporeZoneId = ZoneId.of("Asia/Singapore");
System.out.println("TimeZone : " + singaporeZoneId);
//LocalDateTime + ZoneId = ZonedDateTime
ZonedDateTime asiaZonedDateTime = ldt.atZone(singaporeZoneId);
System.out.println("Date (Singapore) : " + asiaZonedDateTime);
ZoneId newYokZoneId = ZoneId.of("America/New_York");
System.out.println("TimeZone : " + newYokZoneId);
ZonedDateTime nyDateTime = asiaZonedDateTime.withZoneSameInstant(newYokZoneId);
System.out.println("Date (New York) : " + nyDateTime);
DateTimeFormatter format = DateTimeFormatter.ofPattern(DATE_FORMAT);
System.out.println("\n---DateTimeFormatter---");
System.out.println("Date (Singapore) : " + format.format(asiaZonedDateTime));
System.out.println("Date (New York) : " + format.format(nyDateTime));
Output is:
TimeZone : Asia/Singapore
Date (Singapore) : 2015-01-22T10:15:55+08:00[Asia/Singapore]
TimeZone : America/New_York
Date (New York) : 2015-01-21T21:15:55-05:00[America/New_York]
---DateTimeFormatter---
Date (Singapore) : 22-1-2015 10:15:55 AM
Date (New York) : 21-1-2015 09:15:55 PM
Use the methods from here to get what you need
Example taken from: Java – Convert date and time between timezone

simply run your cronjob at every hour and generate only the reports in which timezones the day just ended

java.time
Use a driver compliant with JDBC 4.2 or later, running on Java 8 or later, to benefit from use of the modern java.time classes that supplant the troublesome old legacy date-time classes.
Determining "today" and "yesterday" means determining a date. Determining a date requires a time zone. For any given moment, the date varies around the globe by zone.
ZoneId z = ZoneId.of( "America/Montreal" ) ;
LocalDate today = LocalDate.now( z ) ;
LocalDate yesterday = today.minusDays( 1 ) ;
To query for timestamps in the database, we need specific moments. The Question specifies midnight. The term "midnight" is vague. Let's use "first moment of the day" instead.
Never assume the day starts at 00:00:00. Anomalies such as Daylight Saving Time (DST) mean it may start at another time such as 01:00:00. Let java.time determine first moment of the day.
ZonedDateTime start = yesterday.atStartOfDay( z ) ;
Generally, the best approach to defining a span of time is though the Half-Open approach where the beginning is inclusive while the ending is exclusive. So we want to start at first moment of one day and run up to, but not include, the first moment of the next day.
ZonedDateTime stop = today.atStartOfDay( z ) ;
In Half-Open, we do not use the SQL command BETWEEN.
SQL
SELECT * FROM t
WHERE event >= ? AND event < ? ;
Java
myPreparedStatement.setObject( 1 , start ) ;
myPreparedStatement.setObject( 2 , stop ) ;
To retrieve the timestamps, use getObject.
Instant instant = myResultSet.getObject( "event" , Instant.class ) ;
To move from UTC to a zone, apply a ZoneId.
ZonedDateTime zdt = instant.atZone( z ) ;

Plus 1 hour and 1 day in date using java 8 apis

I have this code to add 1 hour or 1 day in date Java 8, but doesn´t work
String DATE_FORMAT = "yyyy-MM-dd HH:mm:ss";
java.text.SimpleDateFormat format = new java.text.SimpleDateFormat(DATE_FORMAT);
Date parse = format.parse("2017-01-01 13:00:00");
LocalDateTime ldt = LocalDateTime.ofInstant(parse.toInstant(), ZoneId.systemDefault());
ldt.plusHours(1);
ZonedDateTime zdt = ldt.atZone(ZoneId.systemDefault());
Date te = Date.from(zdt.toInstant());
What´s wrong? The code shows: Sun Jan 01 13:00:00 BRST 2017

LocalDateTime is immutable and returns a new LocalDateTime when you call methods on it.
So you must call
ldt = ldt.plusHours(1);

Apart from the issue that you don't use the result of your date manipulation (ldt = ldt.plusHours(1)), you don't really need to go via a LocalDateTime for this operation.
I would simply use an OffsetDateTime since you don't care about time zones:
OffsetDateTime odt = parse.toInstant().atOffset(ZoneOffset.UTC);
odt = odt.plusDays(1).plusHours(1);
Date te = Date.from(odt.toInstant());
You could even stick to using Instants:
Instant input = parse.toInstant();
Date te = Date.from(input.plus(1, DAYS).plus(1, HOURS));
(with an import static java.time.temporal.ChronoUnit.*;)

tl;dr
LocalDateTime.parse( // Parse input string that lacks any indication of offset-from-UTC or time zone.
"2017-01-01 13:00:00".replace( " " , "T" ) // Convert to ISO 8601 standard format.
).atZone( // Assign a time zone to render a meaningful ZonedDateTime object, an actual point on the timeline.
ZoneId.systemDefault() // The Question uses default time zone. Beware that default can change at any moment during runtime. Better to specify an expected/desired time zone generally.
).plus(
Duration.ofDays( 1L ).plusHours( 1L ) // Add a span of time.
)
Details
Do not mix the troublesome old legacy classes Date and Calendar with the modern java.time classes. Use only java.time, avoiding the legacy classes.
The java.time classes use the ISO 8601 standard formats by default when parsing and generating strings. Convert your input string by replacing the SPACE in the middle with a T.
String input = "2017-01-01 13:00:00".replace( " " , "T" ) ;
LocalDateTime ldt = LocalDateTime.parse( input ) ;
ALocalDateTime does not represent an actual moment, not a point on the timeline. It has no real meaning until you assign a time zone.
ZoneId z = ZoneId.systemDefault() ; // I recommend specifying the desired/expected zone rather than relying on current default.
ZonedDateTime zdt = ldt.atZone( z ) ;
A Duration represents a span of time not attached to the timeline.
Duration d = Duration.ofDays( 1L ).plusHours( 1L ) ;
ZonedDateTime zdtLater = zdt.plus( d ) ;