[coverage] Conformance findings: COMPLEX-016

[peco-engineer-bot]

Summary

Surfaced by the multi-language coverage fan-out while conformance-testing these SPEC-IDs against databricks/databricks-jdbc. Each finding is committed as an expected-failure (xfail) test in the coverage PR — the test asserts the CORRECT (post-fix) behavior and stays red until THIS driver (databricks/databricks-jdbc) is fixed, then flips green as a tripwire.

Findings

• COMPLEX-016 [thrift, sea]: Nested TIMESTAMP leaf read as text renders as raw epoch microseconds (1737702461000000) instead of the session-timezone wall clock "2025-01-24 07:07:41" the top-level TIMESTAMP path produces; getObjectWithComplexTypeHandling re-reads the complex column as STRING, bypassing the timestamp formatter.
  • failing test: testNestedTimestampLeafTextSpelling (see the coverage PR diff under tests/)
• COMPLEX-016: A TIMESTAMP leaf nested in STRUCT/ARRAY/MAP read as text renders as raw epoch microseconds (e.g. 1737702461000000) instead of the session-timezone wall clock ("2025-01-24 07:07:41") that the same instant gets as a top-level TIMESTAMP; getObjectWithComplexTypeHandling re-reads the complex column as STRING so the timestamp formatter is bypassed. Affects both thrift and sea.

Reproduce & Expected

COMPLEX-016 — Verify that a TIMESTAMP nested inside a complex type (STRUCT / ARRAY / MAP) and read through the driver's TEXT surface is spelled as the session-timezone wall clock with trailing-zero fractional seco…

Expected (per the shared spec):

• result has exactly 1 row(s)
• result has 3 column(s)
• full assertion contract:

result:
- row_count: 1
- column_count: 3
- nested_leaf_text_spelling:
    column: struct_ts
    leaves:
      ts: '2025-01-24 07:07:41'
- nested_leaf_text_spelling:
    column: array_ts
    leaves:
    - '2024-01-15 12:30:45.123456'
- nested_leaf_text_spelling:
    column: map_ts
    leaves:
      k: '2025-01-24 07:07:41'

Context

• The behavior was first fixed in a DIFFERENT driver — reference PR: https://github.com/databricks/databricks-odbc/pull/215 — which seeded the shared language-neutral spec. This issue tracks the same conformance gap in databricks/databricks-jdbc; the reference PR is for cross-referencing the intended behavior, NOT a change to this repo.
• Coverage PR carrying the reproducing xfail test(s): https://github.com/databricks/databricks-driver-test/pull/1170