Closed mirromutth closed 7 months ago
Looks like merging PR #240 fixes the Micronaut issue. Could you please kindly elaborate on why we need this additional PR? (because it seems half revert of previous change (https://github.com/asyncer-io/r2dbc-mysql/blob/bf4874951e440c8c7ae66f52650918993966d2ad/src/main/java/dev/miku/r2dbc/mysql/MySqlColumnMetadata.java#L135C3-L137C44))
Looks like merging PR #240 fixes the Micronaut issue. Could you please kindly elaborate on why we need this additional PR? (because it seems half revert of previous change (https://github.com/asyncer-io/r2dbc-mysql/blob/bf4874951e440c8c7ae66f52650918993966d2ad/src/main/java/dev/miku/r2dbc/mysql/MySqlColumnMetadata.java#L135C3-L137C44))
It just a very simple idea, which may not be correct: Since there are some problems caused by non-aligned processing of date times and time zones, so I'm trying to ensure that the behavior as same as JDBC.
In JDBC, DATETIME
would map to LocalDateTime
and TIMESTAMP
to Timestamp
which should be re-map to ZonedDateTime
.
Looks like merging PR #240 fixes the Micronaut issue. Could you please kindly elaborate on why we need this additional PR? (because it seems half revert of previous change (https://github.com/asyncer-io/r2dbc-mysql/blob/bf4874951e440c8c7ae66f52650918993966d2ad/src/main/java/dev/miku/r2dbc/mysql/MySqlColumnMetadata.java#L135C3-L137C44))
@jchrys It just a very simple idea, which may not be correct: Since there are some problems caused by non-aligned processing of date times and time zones, so I'm trying to ensure that the behavior as same as JDBC.
In JDBC,
DATETIME
would map toLocalDateTime
andTIMESTAMP
toZonedDateTime
.
Thanks. I understand now, it's clear.
Motivation:
See also #166
Modification:
Change to use default
LocalDateTime
forDATETIME
Result:
Default to use
LocalDateTime
forDATETIME