zhengxiang378928908-code commented on issue #12884: URL: https://github.com/apache/seatunnel/issues/12884#issuecomment-6322885382
@DanielLeens a follow-up on the upgrade path from 2.3.x. In 2.3.13, MySQL `TIMESTAMP` reached the Doris sink as `TIMESTAMP`, a wall-clock value. #10724 (for #10685) changed that mapping to `TIMESTAMP_TZ`, and the later #11524 added `sink.datetime-timezone`, using the JVM default zone when it is unset. That behaviour is documented in `incompatible-changes.md`. On builds with #11524, leaving the option unset can still change the stored wall-clock values compared with 2.3.13 when the JVM zone differs from the zone expected in Doris, and nothing in the logs says so. (The 3.0.0 build in this report predates #11524 and dropped the offset, so it doesn't show which JVM zone was used.) Would a startup warning be welcome? When a `TIMESTAMP_TZ` column is written to Doris and `sink.datetime-timezone` is not set, log the zone that will be used and point to the option. It would not change any behaviour. I can open a PR for it. Deriving the default from Doris itself (for example `@@time_zone` on the catalog's JDBC connection) would be a separate discussion: it changes the default again, and it is not obvious that the catalog session's zone is the right one for stream load. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
