0

I don't understand how the date is parsed in this way and the final result is 1799.

...
@ExpectedDatabase(value = "/dataset/expected/gestionVehicule/doss.xml",
    assertionMode = DatabaseAssertionMode.NON_STRICT_UNORDERED)

In the XML file, the comparing set:
<VEH_DATE_MEC="1800-01-01"/>
...

SimpleDateFormat isoFormat = new SimpleDateFormat("yyyy-MM-dd");
        isoFormat.setTimeZone(TimeZone.getTimeZone("GMT+1"));
        Date date = isoFormat.parse("1800-01-01");
        vehiculeFrontDto.setDatePremiereImmat(date);

The setter:

 public void setDatePremiereImmat(Date datePremiereImmat) {
        this.datePremiereImmat = DateCopyUtils.copyDate(datePremiereImmat);
    }

Date received with the debugger stored in the date variable: Tue Dec 31 23:00:00 UTC 1799

Test: expected:<1[800-01-01]> but was:<1[799-12-31 23:00:00.0]>

Andrew
  • 280
  • 1
  • 3
  • 12
  • 4
    Stop using outdated classes like SimpleDateFormat and java.util.Date. Use classes from the new java.time API instead. – Jens Dec 27 '22 at 08:17
  • 3
    I strongly recommend you do not usew `Date` and `SimpleDateFormat`. Use `LocalDate` from [java.time, the modern Java date and time API](https://docs.oracle.com/javase/tutorial/datetime/index.html). It will also prevent your time zone issue. – Ole V.V. Dec 27 '22 at 11:11
  • 3
    1800-01-01 00:00:00 at GMT offset +01 is the same point in time as 1799-12-31 23:00:00 UTC. So what made you expect something else? Your basic problem is that a `Date` despite its name cannot represent a date. It’s a point in time, and at that point in time it is different dates in different time zones and at different MT offsets. – Ole V.V. Dec 27 '22 at 11:15
  • 2
    `java.time.LocalDate.parse("1800-01-01")` – Basil Bourque Dec 27 '22 at 20:31

0 Answers0