We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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.
isEqualTo(String)
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.
testWithIsEqualTo
(I found the issue with using @DefaultTimeZone, but I can reproduce it without it, so I believe it might be an AssertJ issue).
The text was updated successfully, but these errors were encountered:
Thanks for reporting this @wimdeblauwe, we will have a look at it shortly.
Sorry, something went wrong.
No branches or pull requests
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.Test case reproducing the bug
Add a test case showing the bug that we can run
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).
The text was updated successfully, but these errors were encountered: