RestEasy Jackson test fails in certain time zones

[dmlloyd]

Describe the bug

In the America/Chicago time zone at 2024-03-16 at time 10:59:00 the test io.quarkus.it.resteasy.jackson.GreetingResourceTest#testEndpoint fails with an exception like this:

[ERROR] Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.108 s <<< FAILURE! -- in io.quarkus.it.resteasy.jackson.GreetingResourceTest
[ERROR] io.quarkus.it.resteasy.jackson.GreetingResourceTest.testEndpoint -- Time elapsed: 0.081 s <<< FAILURE!
java.lang.AssertionError: 
1 expectation failed.
JSON path sqlDate doesn't match.
Expected: 2019-01-01
  Actual: 2018-12-31

It looks like a time zone handling problem (hence the zone info above). Notable is that this failure was observed during the period when the US is on DST but other countries are not (this may or may not be a factor but should be considered).

See also #37659 which is likely a related problem.

Expected behavior

No response

Actual behavior

No response

How to Reproduce?

No response

Output of uname -a or ver

Darwin xxxx 23.3.0 Darwin Kernel Version 23.3.0: Wed Dec 20 21:31:00 PST 2023; root:xnu-10002.81.5~7/RELEASE_ARM64_T6020 arm64

Output of java -version

openjdk version "17.0.9" 2023-10-17 OpenJDK Runtime Environment Temurin-17.0.9+9 (build 17.0.9+9) OpenJDK 64-Bit Server VM Temurin-17.0.9+9 (build 17.0.9+9, mixed mode)

Quarkus version or git rev

ffeea8f

Build tool (ie. output of mvnw --version or gradlew --version)

Apache Maven 3.9.5 (57804ffe001d7215b5e7bcb531cf83df38f93546) Maven home: /Users/david/local/apache-maven Java version: 17.0.9, vendor: Eclipse Adoptium, runtime: /Library/Java/JavaVirtualMachines/temurin-17.jdk/Contents/Home Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "14.3.1", arch: "aarch64", family: "mac"

Additional information

No response

[quarkus-bot]

/cc @geoand (jackson), @gsmet (jackson)

[geoand]

cc @ppalaga who introduced the testEndpoint method

[ppalaga]

Thanks for the report @dmlloyd and thanks for pinging me @geoand. The problem seems to be only in the test code, particularly how the test constructs the new java.sql.Date. I think it will start failing also in Europe once we switch to DST on March 31, 2024. Let me try to fix it.