Hello,

I'm using LocalDateTime to represent my timestamps on server side, but would like to transmit data in instant-like format in and out of my API, using the Z timezone. One of the advantages of doing this is that all clients treat the string as referring to the same instance, e.g. "new Date(string)" will result in same interpretation in all browsers, and built-in function such as date.toISOString() exists for formatting the string into an instant in time.

I ran into this behavior in Jackson during deserializing:

The behavior of this line is equivalent to just removing the Z character at end of timestamp and treating the rest as LocalDateTime, e.g. it will return the LocalDateTime in the UTC timezone. Wouldn't it make a lot more sense to convert UTC timestamp to LocalDateTime using system's own timezone, i.e.

LocalDateTime.ofInstant(Instant.parse(string), ZoneId.systemDefault())

so that the time as written by JavaScript would be understood as the same time after Jackson is processing it? I don't think a lot of people expect that a LocalDateTime should be interpreted to be in UTC timezone. For most of us, it's expected to be exactly what it says on the class name: a date and time in the local timezone.