Problem
src/test/java/com/exasol/adapter/dialects/postgresql/PostgreSQLSqlDialectIT.java contains hard-coded expectations for PostgreSQL TIME WITH TIME ZONE and TIMESTAMP WITH TIME ZONE values even though the test setup does not pin the JVM or Exasol session timezone.
The fixture inserts:
- myTimeWithTimeZone: 11:11:11 +01:00
- myTimestampWithTimeZone: 2010-01-01 11:11:11 +01:00
The current test expectation for myTimestampwithtimezone has already needed to move from 2010-01-01 11:11:11 to 2010-01-01 12:11:11, which indicates that the observed value depends on the runtime timezone offset.
Why this is DST-sensitive
The inserted timestamptz value represents a fixed instant: 2010-01-01T10:11:11Z. The test, however, compares it to a local TIMESTAMP without fixing the session timezone. When the environment or session is effectively on UTC+1, the observed local value is 11:11:11; when it is on UTC+2 during daylight saving time, it becomes 12:11:11.
The same risk exists for testDatatypeTimeWithTimezone().
Suggested fix
Make the test deterministic by doing one of the following:
- Pin the timezone used by the test setup before asserting values.
- Set the Exasol session timezone explicitly for the integration test.
- Compute the expected local timestamp dynamically from the effective session timezone instead of hard-coding 11:11:11 or 12:11:11.
Acceptance criteria
PostgreSQLSqlDialectIT passes unchanged in both standard-time and DST periods.- Expectations for
myTimeWithTimeZone and myTimestampwithtimezone no longer depend on the machine or session timezone.
Problem
src/test/java/com/exasol/adapter/dialects/postgresql/PostgreSQLSqlDialectIT.javacontains hard-coded expectations for PostgreSQLTIME WITH TIME ZONEandTIMESTAMP WITH TIME ZONEvalues even though the test setup does not pin the JVM or Exasol session timezone.The fixture inserts:
The current test expectation for myTimestampwithtimezone has already needed to move from 2010-01-01 11:11:11 to 2010-01-01 12:11:11, which indicates that the observed value depends on the runtime timezone offset.
Why this is DST-sensitive
The inserted timestamptz value represents a fixed instant: 2010-01-01T10:11:11Z. The test, however, compares it to a local TIMESTAMP without fixing the session timezone. When the environment or session is effectively on UTC+1, the observed local value is 11:11:11; when it is on UTC+2 during daylight saving time, it becomes 12:11:11.
The same risk exists for
testDatatypeTimeWithTimezone().Suggested fix
Make the test deterministic by doing one of the following:
Acceptance criteria
PostgreSQLSqlDialectITpasses unchanged in both standard-time and DST periods.myTimeWithTimeZoneandmyTimestampwithtimezoneno longer depend on the machine or session timezone.