Update Java to 23.0.2 #24787
Update Java to 23.0.2 #24787
Conversation
wendigo
force-pushed
the
serafin/23.0.2
branch
2 times, most recently
from
ae171c6 to
e4828b0
Compare
wendigo
force-pushed
the
serafin/23.0.2
branch
from
e4828b0 to
6e892b0
Compare
wendigo
force-pushed
the
serafin/23.0.2
branch
8 times, most recently
from
7c28499 to
03593e8
Compare
|
Alternative approach to #24786 |
|
Remaining failures are snowflake related. Some test cases were removed, one test was disabled (delta lake), maybe it's no longer needed. Cc @ebyhr |
wendigo
force-pushed
the
serafin/23.0.2
branch
from
03593e8 to
59e1674
Compare
...in/trino-delta-lake/src/test/java/io/trino/plugin/deltalake/TestDeltaLakeReadTimestamps.java
Outdated
Show resolved
Hide resolved
wendigo
force-pushed
the
serafin/23.0.2
branch
from
2761497 to
5168d64
Compare
|
|
This brings updated timezonedb to version 2024b (openjdk/jdk23u@73b2341) which amends historical timezone definitions for Mexico/Bahia_Banderas that we use for testing timezone gap around the unix timestamp epoch. Corresponding Joda time update also has these timezone definitions updated. PostgreSQL test server was upgraded to 12 to correctly handle UTC around epoch. MySQL was updated to 8.0.41 due to the same reason. Temporary downgrade JDK for ppc64 to make CI happy
wendigo
force-pushed
the
serafin/23.0.2
branch
from
5168d64 to
fb1d2e0
Compare
| } | ||
|
|
||
| @Test | ||
| @Disabled("This test assumes specific tzdb version and it will fail on mismatch between Spark and Trino tzdb versions") |
There was a problem hiding this comment.
isn't this a user-facing issue then?
There was a problem hiding this comment.
What if we update the JDK used to run Spark to the latest patch release for that version?
| @Test | ||
| public void testUnsupportedTimestampWithTimeZoneValues() | ||
| { | ||
| // The range for TIMESTAMP values is '1970-01-01 00:00:01.000000' to '2038-01-19 03:14:07.499999' |
There was a problem hiding this comment.
the comment is still correct, restoring this.
| - offset change since 1970 (offset Jan 1970: -08:00, offset Jan 2018: -06:00) | ||
| - DST (e.g. at 2017-04-02 02:00:00 clocks turned forward 1 hour; 2017-10-29 02:00:00 clocks turned backward 1 hour) | ||
| - has forward offset change on first day of epoch (1970-01-01 00:00:00 clocks turned forward 1 hour) | ||
| - had forward change at midnight (1970-01-01 00:00:00 clocks turned forward 1 hour) |
There was a problem hiding this comment.
That was the reason to use America/Bahia_Banderas in tests. We should switch to a different zone.
This one became nothing special.
There was a problem hiding this comment.
There is no timezone like that anymore in the amended tzdb
There was a problem hiding this comment.
Fair. But again there is no reason to use Bahia anymore. It's a left over now.
4 participants
This brings updated timezonedb to version 2024b
(openjdk/jdk23u@73b2341) which amends historical timezone definitions for Mexico/Bahia_Banderas that we use for testing timezone gap around the unix timestamp epoch.
Corresponding Joda time update also has these timezone definitions updated. PostgreSQL test server was upgraded to 12 to correctly handle
UTC around epoch. MySQL was updated to 8.0.41 due to the same reason.
Description
Additional context and related issues
Release notes
( ) This is not user-visible or is docs only, and no release notes are required.
( ) Release notes are required. Please propose a release note for me.
( ) Release notes are required, with the following suggested text: