Using the following code:
class Test {
public static void main(String [] args) {
LocalDate date = LocalDate.of(2018, 11, 4);
LocalTime time = LocalTime.of(1, 59);
ZonedDateTime dt = ZonedDateTime.of(date, time, ZoneId.of("America/New_York"));
System.out.println(dt.getHour() + ":" + dt.getMinute() + ":" + dt.getSecond());
dt = dt.plusMinutes(1);
System.out.println(dt.getHour() + ":" + dt.getMinute() + ":" + dt.getSecond());
dt = dt.plusMinutes(59);
System.out.println(dt.getHour() + ":" + dt.getMinute() + ":" + dt.getSecond());
dt = dt.plusMinutes(1);
System.out.println(dt.getHour() + ":" + dt.getMinute() + ":" + dt.getSecond());
}
}
I get
1:59:0
1:0:0
1:59:0
2:0:0
Is there a way to get to the 1:00:00 from after daylight saving time without going through the 1:00:00 from before daylight saving time?
Use ofStrict to specify which offset you want the resulting zoned date time to be on. America/New_York changes from -04:00 to -05:00 at around the time in question, so you want ZoneOffset.ofHours(-5).
ZonedDateTime dt = ZonedDateTime.ofStrict(
LocalDateTime.of(date, time),
ZoneOffset.ofHours(-5),
ZoneId.of("America/New_York")
);
In case you cannot hardcode the offset in, you can get the offset after using:
var dateTime = LocalDateTime.of(date, time)
var zone = ZoneId.of("America/New_York");
var offsetAfter = zone.getRules()
.getTransition(dateTime)
.getOffsetAfter();
ZonedDateTime dt = ZonedDateTime.ofStrict(
dateTime,
offsetAfter,
zone
);
Or, as Ole V.V. pointed out, you can also use the much shorter:
ZonedDateTime dt = ZonedDateTime.of(
date, time, ZoneId.of("America/New_York")
).withLaterOffsetAtOverlap();
The problem with time zones that honor Daylight Saving Time is that such times are ambiguous. The "America/New_York" zone has two times that are both labeled 2008-11-04T01:00:00. Technically, one of them is 01:00 EDT and the other is 01:00 EST, but not a lot of software will let you make the distinction that way, not least since such three-letter time zone designations are not necessarily globally unique.
The solution is to specify the time either in or relative to Universal time, which doesn't have daylight saving: the first 01:00 Eastern time is 05:00Z, and the second is 06:00Z. So you can either give the time as one of those and the zone as "UTC" (and then convert the result to "America/New_York"), or specify the offset from UTC using ofStrict.
Related
I know this is an oft asked type of question, and I've been looking around the web for solutions, but to no avail. The problem is that we're fetching a date value from the database and want to display it in a PDF in local time. The raw formatted value is "2022/05/24 15:18:10" and using Costa Rica as an example client time zone (we're in LA), we'd want this "2022/05/24 16:18:10". However, we're getting this: "2022/05/24 17:18:10".
One of the odd things I'm seeing when I run the code below is that it seems that our server time zone is PST, according to Java, but is actually PDT.
creationDate from db=Tue May 24 15:18:10 PDT 2022
Desired creationDate output=2022/05/24 16:18:10
cal.getTimeZone.getDisplayName()=Pacific Standard Time
formatted creationDate=2022/05/24 17:18:10
So one question is: why are we seeing PST instead of PDT and the second question is how do I fix this?
Example code:
public static void main(
String[] args)
{
final String DATE_TIME_PATTERN = "yyyy/MM/dd HH:mm:ss";
final String LA_TIMEZONE_ID = "America/Los_Angeles";
DateFormat df = new SimpleDateFormat(DATE_TIME_PATTERN);
TimeZone serverTimeZone = TimeZone.getTimeZone(LA_TIMEZONE_ID);
Calendar cal = Calendar.getInstance(/* serverTimeZone */); // works same with or without param
TimeZone clientTimeZone = TimeZone.getTimeZone("CST"); // Costa Rica = Central Standard Time
Date creationDate;
df.setTimeZone(clientTimeZone);
// Values as fetched from database.
cal.set(Calendar.DAY_OF_MONTH, 24);
cal.set(Calendar.MONTH, Calendar.MAY);
cal.set(Calendar.YEAR, 2022);
cal.set(Calendar.HOUR_OF_DAY, 15);
cal.set(Calendar.MINUTE, 18);
cal.set(Calendar.SECOND, 10);
creationDate = cal.getTime();
System.out.println("creationDate from db=" + creationDate.toString());
System.out.println("Desired creationDate output=2022/05/24 16:18:10");
System.out.println("cal.getTimeZone.getDisplayName()=" + cal.getTimeZone().getDisplayName());
System.out.println("formatted creationDate=" + df.format(creationDate));
}
So, after a bit of hacking and googling, it would appear (at least to me), that "Central Standard Time" isn't what you want to use (nor should you use it generally).
From time-and-date/Central Standard Time (CST)
Caution: This is NOT the current local time in most locations in that time zone
North America: Only some locations are currently on CST because most places in this time zone are currently on summer time / daylight saving time and are observing CDT.
And then add in time-and-date/Time Zone in Costa Rica
Costa Rica observes Central Standard Time all year. There are no Daylight Saving Time clock changes.
That's not confusing at all 🙄. So, as I "understand" it, CST is normally -6 hours and CDT is -5 hours, but Costa Rica is always -6 hours.
So, based on the observations of your code, CST seems to be having the day light savings value applied to it, regardless of what you do.
So, what to do about it? Well, the simple answer is, don't use it, in fact, stop using the java.util.Date and related APIs altogether and instead, make use of the replacement java.time APIS and the America/Costa_Rica time zone directly, for example...
final String DATE_TIME_PATTERN = "yyyy/MM/dd HH:mm:ss";
final String LA_TIMEZONE_ID = "America/Los_Angeles";
final String dateStringValue = "2022/05/24 15:18:10";
DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy/MM/dd HH:mm:ss");
LocalDateTime ldt = LocalDateTime.parse(dateStringValue, formatter);
ZoneId zoneId = ZoneId.of(LA_TIMEZONE_ID);
ZonedDateTime zdt = ldt.atZone(zoneId);
System.out.println(" Local = " + ldt);
System.out.println(" zdt = " + zdt);
System.out.println("Costa_Rica = " + zdt.withZoneSameInstant(ZoneId.of("America/Costa_Rica")));
System.out.println("US/Central = " + zdt.withZoneSameInstant(ZoneId.of("US/Central")));
which prints...
Local = 2022-05-24T15:18:10
zdt = 2022-05-24T15:18:10-07:00[America/Los_Angeles]
Costa_Rica = 2022-05-24T16:18:10-06:00[America/Costa_Rica]
US/Central = 2022-05-24T17:18:10-05:00[US/Central]
This is probably also a good (and over due) reason to dump the old java.util.Date and related classes and update to the java.time APIs, see the date/time trail for more details
Handling Daylight Savings Time in Java might also be worth a read
Say if i am in BST i.e British Summer Time and i want to execute a job at 19.30 as per the US/Eastern timezone, then how could i acheive it.
Sample code that i tried,
Instant now = Instant.now();
LocalDateTime localTimeNow = LocalDateTime.ofInstant(now, ZoneOffset.systemDefault());
//if BST then use "Europe/London"
//if US/Eastern then use "America/New_York"
// For EST also use "America/New_York"
// If GB-Eire then use "Europe/London"
ZonedDateTime bsTime = now.atZone(ZoneId.of("Europe/London"));
ZonedDateTime nyAmerica = now.atZone(ZoneId.of("America/New_York"));
// Lets calculate the difference between 2 timezones
// Between London and EST
long timeDiff = ChronoUnit.MILLIS.between(bsTime, nyAmerica);
System.out.println("timeDiff - " + timeDiff);
int minutes = (int) ((timeDiff / 1000) / 60);
System.out.println("Time diff bet London and EST - " + minutes + " minutes");
long diff = Duration.between(bsTime, nyAmerica).getSeconds();
int mins = (int) (diff / 60);
System.out.println("Time diff bet London and EST - " + mins + " minutes");
It is giving me Zero in both cases.
What i want is that i have to use this delay to pass it to the executor service as below,
executor.schedule(myRunnable, delay, TimeUnit.SECONDS);
So even though i am in Britain, the job should get executed at at 19.30 as per the US/Eastern.
Also some of the abbreviations like EST, BST are not a valid ZoneId.
So how could i handle those cases when i have timezone in an abbreviated format like EST or BST etc. ?
UPDATE: Original answer below shows how to calculate local time to start a job that must run at a certain time of day in a different time zone.
If you just want to calculate how long to wait until that time, it can be done much easier, without involving the local time zone.
LocalTime jobStartTime = LocalTime.of(19, 30);
ZoneId jobZone = ZoneId.of("America/New_York");
ZonedDateTime now = ZonedDateTime.now(jobZone);
ZonedDateTime jobDateTime = now.with(jobStartTime);
if (jobDateTime.isBefore(now))
jobDateTime.plusDays(1);
long delay = ChronoUnit.MILLIS.between(now, jobDateTime);
System.out.println("now = " + now);
System.out.println("jobDateTime = " + jobDateTime);
System.out.println("delay = " + delay + " = " + Duration.ofMillis(delay));
Output
now = 2020-07-17T08:18:45.482028800-04:00[America/New_York]
jobDateTime = 2020-07-17T19:30-04:00[America/New_York]
delay = 40274517 = PT11H11M14.517S
Original Answer
now is 2020-07-17 07:57:45 Z
In London that is 2020-07-17 08:57:45 +01:00
In New York that is 2020-07-17 03:57:45 -04:00.
What is the time different between London and New York?
0 seconds, because they are the same time.
The code in the question doesn't calculate when the time will be 19:30. Instead, it attempts to calculates the time zone difference as of right now, but because of Daylight Savings Time, the time zone difference at 7:30 PM might be different, so the approach is wrong.
If you are in London, and need to know when it will next be 19:30 in New York, do it like this:
Instant now = Instant.now();
ZoneId localZone = ZoneId.of("Europe/London");
ZoneId remoteZone = ZoneId.of("America/New_York");
System.out.println("now = " + now);
ZonedDateTime remoteNow = now.atZone(remoteZone);
LocalDate remoteDate = remoteNow.toLocalDate();
LocalTime remoteTime = LocalTime.of(19, 30);
if (remoteNow.toLocalTime().isAfter(remoteTime))
remoteDate = remoteDate.plusDays(1);
ZonedDateTime remoteStartTime = ZonedDateTime.of(remoteDate, remoteTime, remoteZone);
System.out.println("remoteNow = " + remoteNow);
System.out.println("remoteStartTime = " + remoteStartTime);
ZonedDateTime localStartTime = remoteStartTime.withZoneSameInstant(localZone);
System.out.println("localNow = " + now.atZone(localZone));
System.out.println("localStartTime = " + localStartTime);
Output
now = 2020-07-17T07:57:45.206007800Z
remoteNow = 2020-07-17T03:57:45.206007800-04:00[America/New_York]
remoteStartTime = 2020-07-17T19:30-04:00[America/New_York]
localNow = 2020-07-17T08:57:45.206007800+01:00[Europe/London]
localStartTime = 2020-07-18T00:30+01:00[Europe/London]
So, on a computer running British time zone, the next 7:30 PM time in Eastern US is at half past midnight tonight.
You could try to use Spring Boot Quartz Scheduler
Reference: https://www.callicoder.com/spring-boot-quartz-scheduler-email-scheduling-example/
I want to convert the given HH:mm from UTC to different time zones.
String myDateString = "02:30";
LocalTime localTime = LocalTime.parse(myDateString, DateTimeFormatter.ofPattern("HH:mm"));
int hour = localTime.get(ChronoField.CLOCK_HOUR_OF_DAY);
int minute = localTime.get(ChronoField.MINUTE_OF_HOUR);
int second = localTime.get(ChronoField.SECOND_OF_MINUTE);
System.out.println("UTC Time is "+ hour + ":" + minute);
Calendar pstTime = new GregorianCalendar(TimeZone.getTimeZone("America/Los_Angeles"));
hour = pstTime.get(hour);
minute = pstTime.get(minute);
getting error with this. any help appreciated.
Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException:
30
As already said, a time zone without day part misses information considering DST.
So it is:
String myDateString = "02:30";
LocalTime localTime = LocalTime.parse(myDateString,
DateTimeFormatter.ofPattern("HH:mm"));
LocalDateTime localDateTime = localTime.atDate(LocalDate.now());
System.out.println("localDateTime: " + localDateTime);
ZonedDateTime zonedDateTimeUTC = localDateTime.atZone(ZoneId.of("UTC"));
System.out.println("zonedDateTimeUTC: " + zonedDateTimeUTC);
ZonedDateTime zonedDateTimePST = zonedDateTimeUTC.withZoneSameInstant(
ZoneId.of("America/Los_Angeles"));
System.out.println("zonedDateTimePST: " + zonedDateTimePST);
int hour = zonedDateTimePST.getHour();
int minute = zonedDateTimePST.getMinute();
int second = zonedDateTimePST.getSecond();
There is no need for the old Calendar class.
I think you should specify date too. For that problem you can use this block of code
DateTimeFormatter DATE_TIME_FORMATTER = DateTimeFormatter
.ofPattern("MM/dd/yyyy'T'HH:mm z");
String inputValue = "08/03/2020T15:20 UTC";
ZonedDateTime zdtInstanceAtOffset = ZonedDateTime.parse(inputValue, DATE_TIME_FORMATTER);
ZonedDateTime zonedDateTime = zdtInstanceAtOffset.withZoneSameInstant(ZoneId.of("America/Los_Angeles"));
System.out.println(zonedDateTime);
Without a date, you can convert a time, given for one timezone, to another timezone only by adding/subtracting the time difference between the source timezone and the target timezone to/from the given time.
The problem with this approach is, that the time difference between timezones is not constant over the year, when it is identified by "region/location" (like "America/Los Angeles"). If you use "EST" or "GMT" or "CET" (sometimes referred to as "zone times") instead, the differences would be stable – but you are still inaccurate: several timezones will have two zone times, depending on the time in the year …
You can use the java.time.ZonedDateTime class for this and the method withZoneSameInstant(ZoneId zone) which returns a copy of the datetime in the specified zone.
Here is an example if your input time is in UTC timezone. To change the zone of the input time change Zone inputZone to ZoneId.of("<your timezone>");
public static void main(String[] args) {
String timeString = "02:30";
// Change this to the zone of the input time
ZoneId inputZone = ZoneId.of("UTC");
// Parse your input into time
LocalTime time = LocalTime.parse(timeString);
// Add current date to the time, you can add custom date using LocalDate.of(int year, int month, int dayOfMonth)
LocalDateTime localDateTime = time.atDate(LocalDate.now());
// Declare zoned date time with input zone specified
ZonedDateTime zonedDateTime = localDateTime.atZone(inputZone);
// Declare zones you will use
ZoneId myZone = ZoneId.systemDefault();
ZoneId utcZone = ZoneId.of("UTC");
ZoneId nyZone = ZoneId.of("America/New_York");
ZoneId tokyoZone = ZoneId.of("Asia/Tokyo");
// Get times in different timezones
ZonedDateTime myDateTime = zonedDateTime.withZoneSameInstant(myZone);
ZonedDateTime utcDateTime = zonedDateTime.withZoneSameInstant(utcZone);
ZonedDateTime nyDateTime = zonedDateTime.withZoneSameInstant(nyZone);
ZonedDateTime tokyoDateTime = zonedDateTime.withZoneSameInstant(tokyoZone);
// Print the times in different timezones
System.out.println("My Timezone: " + myDateTime);
System.out.println("UTC: " + utcDateTime);
System.out.println("NY: " + nyDateTime);
System.out.println("Tokyo: " + tokyoDateTime);
// Print without the offset
System.out.println("My Timezone: " + myDateTime.format(DateTimeFormatter.ISO_LOCAL_DATE_TIME));
System.out.println("UTC: " + utcDateTime.format(DateTimeFormatter.ISO_LOCAL_DATE_TIME));
System.out.println("NY: " + nyDateTime.format(DateTimeFormatter.ISO_LOCAL_DATE_TIME));
System.out.println("Tokyo: " + tokyoDateTime.format(DateTimeFormatter.ISO_LOCAL_DATE_TIME));
}
This code will generate the following output:
My Timezone: 2020-03-11T03:30+01:00[Europe/Zagreb]
UTC: 2020-03-11T02:30Z[UTC]
NY: 2020-03-10T22:30-04:00[America/New_York]
Tokyo: 2020-03-11T11:30+09:00[Asia/Tokyo]
My Timezone: 2020-03-11T03:30:00
UTC: 2020-03-11T02:30:00
NY: 2020-03-10T22:30:00
Tokyo: 2020-03-11T11:30:00
I know that there are tons of different tutorials on time conversion, but this one got me very confused. My task is to read UTC DATE from Oracle DB and convert it into BST time (in a more human readable format).
Facts:
Field in the DB is of DATE type.
When i perform SELECT query it returns 2011-07-12 15:26:07 result.
I'm located in Poland, hence in July the TimeZone here is UTC+2
What's happening:
On the Java side I'm using "classical" JDBC connection to the DB.
When I perform Timestamp timestampDate = resultSet.getTimestamp(COLUMN_NAME) I get the result ... but ...
System.out.println(timestampDate) prints to the console 2011-07-12 15:26:07.0 (which is similar to what I see in the DB tool.
System.out.println(timestampDate.getTime()); prints to the console 1310477167000 (which is wondering, because according to the ms to date converter i found online, it's basically 2011-07-12 13:26:07.0 (2h earlier - which somehow might be related to Polish timezone on that date)
When I perform conversion according to this code:
ukDateFormatter = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
ukDateFormatter.setTimeZone(TimeZone.getTimeZone("BST"));
return ukDateFormatter.format(timestampDate.getTime());
I get 2011-07-12 19:26:07 which I can't really explain.
I was also trying this
GregorianCalendar calendar = new GregorianCalendar();
calendar.setTime(timestampDate);
calendar.setTimeZone(TimeZone.getTimeZone("BST"));
return ukDateFormatter.format(calendar.getTime());
with the same result.
Question
How to properly read DATE from Oracle DB in "timezone agnostic" format and convert it into BST?
Here's a way of doing it in the database side:
with dates as (select to_date('01/07/2016 10:39:29', 'dd/mm/yyyy hh24:mi:ss') dt from dual union all
select to_date('01/02/2016 09:18:41', 'dd/mm/yyyy hh24:mi:ss') dt from dual)
select dt,
cast(dt AS TIMESTAMP) utc_dt_ts,
from_tz(cast(dt AS TIMESTAMP), 'UTC') AT time zone 'Europe/London' dt_as_ts_bst,
cast(from_tz(cast(dt AS TIMESTAMP), 'UTC') AT time zone 'Europe/London' AS DATE) dt_at_bst
from dates;
DT UTC_DT_TS DT_AS_TS_BST DT_AT_BST
------------------- ------------------------------------------------- ------------------------------------------------- -------------------
01/07/2016 10:39:29 01-JUL-16 10.39.29.000000 01-JUL-16 11.39.29.000000 EUROPE/LONDON 01/07/2016 11:39:29
01/02/2016 09:18:41 01-FEB-16 09.18.41.000000 01-FEB-16 09.18.41.000000 EUROPE/LONDON 01/02/2016 09:18:41
The fourth column (dt_at_bst) is the one that shows how to take the date and turn it into another date at BST. It does this by first casting the date as a timestamp and then telling Oracle to treat it as a timestamp at UTC and to output the timestamp for the 'Europe/London' region. Specifying the region like this (rather than passing a specific +01:00 timezone) means that the resultant timestamp will be daylight savings aware. Specifying the region as a three letter shortcut is not advised since that may represent more than one region - e.g. BST could be British Summer Time or Bering Standard Time; both very different things!
I have assumed that by BST you mean British Summer Time, so I have specified the region for the timestamp to be moved to as Europe/London. You would need to adjust this as applicable, if you need a different timezone.
I have included a winter and a summer date in my sample data to show you the effects of casting it into BST - the summer time is expecting to be changed, and the winter time is not.
Actually it is not about Oracle, but more about Java.
First of all:
When you use
System.out.println(timestampDate)
in output you see already adjusted time to your computer time zone.
It is always adjusted when you use Date (i.e.
Calendar.getTime() or Timestamp.getTime())
Code to play with:
SimpleDateFormat dtFmt = new SimpleDateFormat("HH:mm:ss");
NumberFormat nFmt = NumberFormat.getIntegerInstance();
nFmt.setMinimumIntegerDigits(2);
long currentTimeMs = System.currentTimeMillis();
GregorianCalendar utcCalendar = new GregorianCalendar(
TimeZone.getTimeZone("UTC"));
GregorianCalendar bstCalendar = new GregorianCalendar(
TimeZone.getTimeZone("Europe/London"));
GregorianCalendar localCalendar = new GregorianCalendar();
utcCalendar.setTimeInMillis(currentTimeMs);
bstCalendar.setTimeInMillis(currentTimeMs);
localCalendar.setTimeInMillis(currentTimeMs);
System.out.println("---- milliseconds ----");
System.out.println("Current ms : " + currentTimeMs);
System.out.println("Local Calendar ms: " + localCalendar.getTimeInMillis());
System.out.println("UTC Calendar ms: " + utcCalendar.getTimeInMillis());
System.out.println("BST Calendar ms: " + bstCalendar.getTimeInMillis());
System.out.println("---- SimpleFormat Time ----");
System.out.println("Current Time: "
+ dtFmt.format(new Date(currentTimeMs)));
System.out.println("Local Time: " + dtFmt.format(localCalendar.getTime()));
System.out.println("UTC Time : " + dtFmt.format(utcCalendar.getTime()));
System.out.println("BST Time : " + dtFmt.format(bstCalendar.getTime()));
System.out.println("---- Calendar Zone Time ----");
System.out.println("Local Zone Time: "
+ nFmt.format(localCalendar.get(Calendar.HOUR_OF_DAY)) + ":"
+ nFmt.format(localCalendar.get(Calendar.MINUTE)) + ":"
+ nFmt.format(localCalendar.get(Calendar.SECOND)));
System.out.println("UTC Zone Time : "
+ nFmt.format(utcCalendar.get(Calendar.HOUR_OF_DAY)) + ":"
+ nFmt.format(utcCalendar.get(Calendar.MINUTE)) + ":"
+ nFmt.format(utcCalendar.get(Calendar.SECOND)));
System.out.println("BST Zone Time : "
+ nFmt.format(bstCalendar.get(Calendar.HOUR_OF_DAY)) + ":"
+ nFmt.format(bstCalendar.get(Calendar.MINUTE)) + ":"
+ nFmt.format(bstCalendar.get(Calendar.SECOND)));
}
As you will see each Calendar returns Time fields (HOUR_OF_DAY, MINUTE, SECOND) according to its TimeZone, not what you print or format from Calendar.getTime())
What I did, and it seems to be working for me:
ukDateFormatter = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
ukDateFormatter.setTimeZone(TimeZone.getTimeZone("Europe/London"));
and performing:
Timestamp timestampDate = rs.getTimestamp(...);
DateTime dateTime = new
DateTime(timestampDate).withZoneRetainFields(DateTimeZone.UTC);
System.out.println(ukDateFormatter.format(dateTime.getMillis()));
prints:
2011-07-12 16:26:07 from the input 2011-07-12 15:26:07
Why happened here?
What was so problematic here, is that rs.getTimestamp(...) was returning the date from the database "as it is" (since DATE column type doesn't preserve the timezone) implicitly but was adding some information about my local timezone - which I didn't wanted.
Easiest solution was to use joda and create new object, retaining values, but changing timezone to UTC. From that point conversion with SimpleDateFormat is quite straightforward.
I can't seem to figure out why joda time is updating the time and offset hours after daylight saving time, but java time doesn't.
DateTime dateTime = new DateTime("2016-04-05T10:06:21.636-05:00").withDayOfWeek(5);
TemporalField dayOfWeek = WeekFields.ISO.dayOfWeek();
OffsetDateTime offsetDateTime = OffsetDateTime.parse("2016-04-05T10:06:21.636-05:00").with(dayOfWeek, 5);
ZonedDateTime zonedDateTime = ZonedDateTime.parse("2016-04-05T10:06:21.636-05:00").with(dayOfWeek, 5);
System.out.println("dateTime: " + dateTime); // 2016-04-08T11:06:21.636-04:00
System.out.println("offsetDateTime: " + offsetDateTime); // 2016-04-08T10:06:21.636-05:00
System.out.println("zonedDateTime: " + zonedDateTime); // 2016-04-08T10:06:21.636-05:00
Time zone versus offset
You did not provide a time zone, only an offset to both, the offset date time and the zoned date time instances. In both cases, they don't have any clue about daylight saving times as this is an information of the time zone.
So you must provide a time zone when constructing the zoned date time object, and it then it works as you expect.