LocalDateDeserializer ignores local time zone

[pherklotz]

I expect the LocalDateDeserializer to return a date in the local time zone.

Following snippet can reproduce the wrong behaviour.

ObjectMapper mapper = new ObjectMapper();
mapper.registerModule(new JavaTimeModule());
LocalDate date = mapper.readValue("\"2017-12-31T23:00:00.000Z\"", LocalDate.class);
System.out.println(date); // Output: 2017-12-31

IMHO should this code executed in GMT+1 print "2018-01-01".
This could be easily fixed. Replace this line:

// com.fasterxml.jackson.datatype.jsr310.deser.LocalDateDeserializer.deserialize(JsonParser, DeserializationContext)
...
// replace this
return LocalDateTime.ofInstant(Instant.parse(string), ZoneOffset.UTC).toLocalDate();
// with this
return ZonedDateTime.parse(string).withZoneSameInstant(ZoneId.systemDefault()).toLocalDate();

[cowtowncoder]

I am not sure why you think local timezone should be used for anything -- Jackson does not use it for anything by default, due to fundamental fragility of relying on something that essentially varies arbitrarily. Instead, default timezone is UTC.
But you can change that easily enough if you want to.

Further, LocalDate does NOT mean it is in local timezone or such, but rather that date/time value is independent of timezone and essentially has not meaning without being bound to specific timezone. Name may be seen bit misleading by Javadocs explains it:

https://docs.oracle.com/javase/8/docs/api/java/time/LocalDate.html

So, I do not see behaviour here as wrong -- especially since use of date.toString() for printing out itself tells very little about actual value -- it may use whatever formatting and timezone settings you happen to have.

[pherklotz]

Thank you for your time and your explanation. I assumed LocalDate represents a date in the local time zone and not a date without time zone.

[cowtowncoder]

@pherklotz Yes, I can see how name would imply that. Naming is hard, and I am not quite sure why Java 8 name was chosen this way.

[dariotortola]

@cowtowncoder The local timezone may not be important, but take this case:
Web application, a particular date is saved as LocalDate because it actually does not care about time zone.
The user being in GMT+2 zone, picks Apr 30th 2020, so he'll expect to see Apr 30th 2020 back, however, he sees Apr 29th 2020.
How:
The user chose Apr 30th 2020, he is in GMT+2.
Since it is a date object, javascript sends it as "2020-04-29T22:00:00.000Z"
In backend they expect a LocalDate so Jackson translates that string. Since it does not care about the locale of the user, the date becomes Apr 29th 2020.
So while the server's locale should not be used, the locale of the request should.
And btw, this is a real case in the application I work in right now

[kupci]

@dariotortola I think the issue you mention might be fixed/addressed with #94

[fsomme2s]

@kupci I'm afraid not - the scenario described by dariotortola is not handled by #94 - I just updated jackson to newest version in the hope it would be, but the fix of #94 is:

if (string.endsWith("Z")) {
     if (isLenient()) {
         return LocalDateTime.parse(string.substring(0, string.length()-1),
                 _formatter);
     }

So this basically means: cut off the Z and parse it as "2020-04-29T22:00:00.000".

Also if this string should be parsed as LocalDate (without Time) the code goes like this with the same result:

return string.endsWith("Z") ? LocalDateTime.ofInstant(Instant.parse(string), ZoneOffset.UTC).toLocalDate() : ...;

So long story short: I think you must tell your client somehow not to convert the "2020-04-30" into a "2020-04-29T22:00:00.000Z" when sending it to the server.

If I am mistaken somewhere and there actually is a way to configure jackson to make a "2020-04-29T22:00:00Z" into "200-04-30"-LocalDate, please tell me! It would be very helpful!