isEqualTo on date can lead to unexpected failures when switching time zones #3382
Description
Describe the bug
The behaviour of isEqualTo(String) when asserting a java.util.Date can fail if you switch the default time zone during a test run.
- assertj core version: 3.24.2
- java version: 21
- test framework version: JUnit 5
- os (if relevant):
Test case reproducing the bug
Add a test case showing the bug that we can run
public class Test {
@Test
void testWithIsEqualTo() {
// TimeZone.setDefault(TimeZone.getTimeZone("CET"));
// assertThat(Date.from(Instant.parse("2024-03-01T00:00:00.000+01:00")))
// .describedAs("Using CET time zone")
// .isEqualTo("2024-03-01");
TimeZone.setDefault(TimeZone.getTimeZone("WET"));
assertThat(Date.from(Instant.parse("2024-03-01T00:00:00.000+00:00")))
.describedAs("Using WET time zone")
.isEqualTo("2024-03-01");
}
@Test
void test() {
// TimeZone.setDefault(TimeZone.getTimeZone("CET"));
// assertThat(Date.from(Instant.parse("2024-03-01T00:00:00.000+01:00")))
// .describedAs("Using CET time zone")
// .hasYear(2024)
// .hasMonth(3)
// .hasDayOfMonth(1);
TimeZone.setDefault(TimeZone.getTimeZone("WET"));
assertThat(Date.from(Instant.parse("2024-03-01T00:00:00.000+00:00")))
.describedAs("Using WET time zone")
.hasYear(2024)
.hasMonth(3)
.hasDayOfMonth(1);
}
}Run this test with the code commented out. The test will be ok.
Now enable the code in comments and run the test again. The test testWithIsEqualTo now fails, but on the part that was already active before.
(I found the issue with using @DefaultTimeZone, but I can reproduce it without it, so I believe it might be an AssertJ issue).
Metadata
Metadata
Assignees
Labels
No labels