Liquibase changelog: TIMESTAMP WITH TIME ZONE or TIMESTAMP WITHOUT TIME ZONE for cross-vendor UTC?

Assumes Liquibase 4.x targeting PostgreSQL, MySQL, and Oracle. The goal is to store logical event timestamps consistently across vendors without regional wall-clock drift when changelogs run from application servers in different time zones.

Liquibase has no standalone change-type attribute that forces UTC storage, so conversion is delegated to the target database and its JDBC driver session. PostgreSQL TIMESTAMP WITH TIME ZONE stores UTC internally and renders to the session time zone, while MySQL TIMESTAMP converts session time to UTC on write and back on read, but DATETIME does not. Oracle has its own TIMESTAMP WITH TIME ZONE semantics. A changeSet using CURRENT_TIMESTAMP records the database server clock at execution time, so regional servers may observe different values.

The unresolved decision is whether to declare timestamp columns as WITH TIME ZONE and rely on database conversion, or use WITHOUT TIME ZONE and normalize values in the application layer before insertion. Mixing the two types across changelogs can cause diff drift or false-positive changeSets.

Which approach better preserves consistent UTC semantics across PostgreSQL, MySQL, and Oracle in Liquibase changelogs? Should CURRENT_TIMESTAMP defaults be avoided or replaced with application-supplied UTC values? How should diffChangeLog be configured to avoid false positives when source databases report different time-zone column types?