loserwang1024 commented on PR #4181:
URL: https://github.com/apache/flink-cdc/pull/4181#issuecomment-4541276980
> I am not sure if server-time-zone affects TIMESTAMPTZ.
@Fluder-Paradyne
No influence. I have see the code of debezium. In Debezium's PostgreSQL
connector, timestamp with time zone values are always normalized to UTC+0
regardless of the data source path. Here's why:
### Streaming Path (pgoutput logical replication)
When consuming WAL via the pgoutput plugin, the value goes through
`AbstractColumnValue.asOffsetDateTimeAtUtc()` :
```java
return DateTimeFormat.get()
.timestampWithTimeZoneToOffsetDateTime(asString()) // Step 1: parse
raw text with original offset
.withOffsetSameInstant(ZoneOffset.UTC); // Step 2:
normalize to UTC+0
```
The pgoutput protocol delivers column values as UTF-8 text strings (e.g.,
"2019-10-02T13:51:30.123456+02:00"). The parser first produces an
OffsetDateTime with the original timezone offset from the WAL entry, then
explicitly converts it to UTC via .withOffsetSameInstant(ZoneOffset.UTC). This
guarantees the OffsetDateTime entering convertTimestampWithZone() is always at
offset zero.
### Snapshot Path (JDBC)
During initial snapshots, the JDBC driver returns java.sql.Timestamp (a
subclass of java.util.Date). In convertTimestampWithZone():
```java
if (data instanceof java.util.Date) {
data = OffsetDateTime.ofInstant(((Date) data).toInstant(),
ZoneOffset.UTC);
}
```
java.util.Date.toInstant() yields an absolute point in time (epoch-based),
and OffsetDateTime.ofInstant(..., ZoneOffset.UTC) renders it explicitly at
UTC+0.
--
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]
