Why LocalDateDeserializer used UTC ?

[ChaceYang]

Why LocalDateDeserializer used UTC?
Closed issue LocalDateDeserializer ignores local time zone

JDK use system default zone.

    public static LocalDateTime now() {
        return now(Clock.systemDefaultZone());
    }

    public static LocalDateTime now(Clock clock) {
        Objects.requireNonNull(clock, "clock");
        Instant now = clock.instant();
        ZoneOffset offset = clock.getZone().getRules().getOffset(now);
        return ofEpochSecond(now.getEpochSecond(), now.getNano(), offset);
    }

Maybe LocalDateDeserializer used UTC is worst?

[cowtowncoder]

What exactly is your problem here? Jackson defaults to UTC for most things, and "local" dates/times mean that there is NO TIMEZONE associated at all:

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

so one SHOULD NOT USE timezone with LocalDateTime and others, nor expect specific one, nor make any other assumptions.

[GedMarc]

Correct, for zoning use ZonedDateTime and pull it back to LocalDate with a .asDate() to correctly shift between zones.

LocalDateTime and LocalDate are always in UTC, and this is correct. Please do not change this at all!

@funcfoo Perhaps look at your requirements and verify if you are using the correct objects.
@cowtowncoder Is there a ZonedDateTime serializer that takes a ZoneId as a parameter?

[ChaceYang]

@cowtowncoder @GedMarc
LocalDateTime and LocalDate is NO TIMEZONE associated.
I agree with this.

so. I think is user defined.
we can be setting it in properties.

[ChaceYang]

English is not my first language.

I'm not sure whether I make myself clear.

Long time passed. so I close this issue.

[cowtowncoder]

I think that I understood enough to try to explain why I think handling is reasonable at this point, and that user needs to handle TimeZone separately from deserialization.
So I don't think I want to change handling.