Bug report

When the server where Oracle is located is not in the zero time zone(e.g. UTC+08:00), the time of getting the data to be changed in the Oracle database (i.e source. ts_ms) is several hours longer than the actual time. (e.g. Eight-hour gap)

This is because this field is derived from CHANGE_TIME in the Oracle view V$LOGMNR_CONTENTS . CHANGE_TIME is in the database server time zone, but does not store the time zone. Therefore, the Oracle connector just arbitrarily transfers UTC calendar for time conversion.

See: 

1. io.debezium.connector.oracle.logminer.LogMinerStreamingChangeEventSource.execute(LogMinerStreamingChangeEventSource.java:187)
2. io.debezium.connector.oracle.logminer.LogMinerQueryResultProcessor.processResult(LogMinerQueryResultProcessor.java:109)
3. io.debezium.connector.oracle.logminer.RowMapper.getChangeTime(RowMapper.java:85)

What Debezium connector do you use and what version?

Oracle debezium connector, version: release-2.2

What is the connector configuration?

Default configuration only

What is the captured database version and mode of depoyment?

Oracle 12c, just one instance

What behaviour do you expect?

The time of getting the data to be changed in the Oracle database (i.e source. ts_ms) is correct.

What behaviour do you see?

The source.ts_ms is several hours longer than the actual time.

Do you see the same behaviour using the latest relesead Debezium version?

Yes.

How to reproduce the issue using our tutorial deployment?

You only need to select an Oracle database that is not in the zero time zone to reproduce the issue.

Feature request or enhancement

For feature requests or enhancements, provide this information, please:

Which use case/requirement will be addressed by the proposed feature?

Correct data change time can help users better determine the lag between the source database update and Debezium.