You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 13, 2023. It is now read-only.
Hi, I've read #151, and I agree to avoid java.sql.Date and java.sql.Timestamp. And I agree JSR-310 types have significant advantages against java.util.Date. But I still think it's necessary to support java.util.Date.
For example, when a LocalDateTime serialize to JSON, by default it turns to things like "[2022,6,27,18,50,17,312372640]". First, it's more complex to deserialize. Second, there's no timezone info in it. Yes, I know there are OffsetDateTime and ZonedDateTime. But both of them serialize to things like "1656328666.118132193". All of these are quite different from the serialization result of java.util.Date. That means they'll break old codes.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hi, I've read #151, and I agree to avoid java.sql.Date and java.sql.Timestamp. And I agree JSR-310 types have significant advantages against java.util.Date. But I still think it's necessary to support java.util.Date.
For example, when a LocalDateTime serialize to JSON, by default it turns to things like "[2022,6,27,18,50,17,312372640]". First, it's more complex to deserialize. Second, there's no timezone info in it. Yes, I know there are OffsetDateTime and ZonedDateTime. But both of them serialize to things like "1656328666.118132193". All of these are quite different from the serialization result of java.util.Date. That means they'll break old codes.
The text was updated successfully, but these errors were encountered: