isEqualTo on date can lead to unexpected failures when switching time zones

[wimdeblauwe]

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).

[joel-costigliola]

Thanks for reporting this @wimdeblauwe, we will have a look at it shortly.