[DRAFT] Add support for TIMESTAMP types in Exasol connector

[skyglass]

Description

Improved version of the previous PR: #26259
Added Exasol Trino connector support for Timestamp and Timestamp With Local Time Zone JDBC data types

Additional context and related issues

• Exasol TIMESTAMP type is mapped to Trino TIMESTAMP type
• Exasol TIMESTAMP WITH LOCAL TIME ZONE type is mapped to Trino TIMESTAMP type
• added correspondent tests for timestamp with precision data type
• added correspondent tests for timestamp with local time zone with precision data type
• added tests for DST gap and DST overlap times in "America/Bahia_Bandera" JVM time zone

Release notes

## Exasol Connect
* Add support for `timestamp` and `timestamp with local time zone` types. 

[skyglass]

improved PR, with more simple and less error-prone solution.
The previous PR is moved to DRAFT, please discard it: #26259

Please, review the new PR, @ebyhr , @chenjian2664 ! 🙏

After reviewing the previous implementation, I believe the previous approach - mapping Exasol TIMESTAMP WITH LOCAL TIME ZONE to Trino TIMESTAMP WITH TIME ZONE - adds unnecessary complexity and potential pitfalls.

Exasol TIMESTAMP WITH LOCAL TIME ZONE does not actually persist any time zone information. Apart from some minor edge cases, its semantics is very close to a plain Exasol TIMESTAMP.

Mapping to Trino TIMESTAMP WITH TIME ZONE requires hardcoding the JVM time zone, which introduces fragility. For example, values valid in the Exasol DB time zone but invalid in the JVM time zone (e.g., during DST gaps) may cause Trino to throw exceptions, potentially breaking queries.

A simpler mapping to Trino TIMESTAMP avoids these problems, is more efficient, and aligns better with how Exasol handles this type internally.

Given this, I created a new PR proposing the TIMESTAMP WITH LOCAL TIME ZONE → TIMESTAMP mapping, which I believe will result in a cleaner, simpler and more reliable solution.

[skyglass]

Thank you very much for your review, @ebyhr ! 👍

The changes have been applied.

[github-actions]

This pull request has gone a while without any activity. Ask for help on #core-dev on Trino slack.

[chenjian2664]

The https://docs.exasol.com/db/latest/sql_references/data_types/datatypedetails.htm#Dateandtimedatatypes shows that timestamp with local time zone type actually has timezone concept, but just store as UTC.

How about support only TIMESTAMP type first in this single pr?

[skyglass]

The https://docs.exasol.com/db/latest/sql_references/data_types/datatypedetails.htm#Dateandtimedatatypes shows that timestamp with local time zone type actually has timezone concept, but just store as UTC.

Yes, it has some differences in the time zone behavior, than usual TIMESTAMP, which are reflected in the tests, but when we get the actual column value with trino connector reader we don't know, in which time zone it was saved. So if we map to Trino "Timestamp With Time Zone" we must provide some time zone, which could be hardcoded UTC or JVM Time Zone. But this approach is more fragile and in some extreme cases like DLT, could even provide incorrect mapping. So the solution of mapping to Trino Timestamp is more simple and less error-prone.

How about support only TIMESTAMP type first in this single pr?

The implementations are actually very similar and the second PR would be a change of just two lines of code in the main source and one line in documentation (the tests are also very similar for each type).
This is due to a more simple solution, which maps to Trino Timestamp for both Exasol Types.

[skyglass]

Thank you very much for your review, @chenjian2664 👍

The new PR, which contains only TIMESTAMP changes, has been created:
#26963

I will close this PR

[skyglass]

Closed as Draft.
The new PR, which contains only TIMESTAMP changes has been created
#26963