Hi, I've read https://github.com/mirromutth/r2dbc-mysql/issues/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.
Hi, I've read https://github.com/mirromutth/r2dbc-mysql/issues/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.