Several blockers; please mark this as draft as the description suggests, or address before merge.

Re-review on tip 7edb1df (force-pushed since the prior review on 8b53059). Several of my prior blockers were silently fixed without a reply (good); a few are not yet addressed; and the new force-push introduced regressions in cast_to_TimestampTz_s and a Python test file that won't even parse. PR is now draft, which is the right call.

Prior blockers — status

• timestamp.rs SerializeWithContext using timestamp_format instead of timestamp_tz_format — fixed.
• serialize_table_record!(TestStruct[3] {...}) field count — fixed (now [4]).
• DBSPTypeTimestampTz getMaxValue 8 nines — fixed (6 nines).
• CastTests Americas/New_York — fixed.
• TypeCompiler TZ branch warning text + precision constant — fixed (note: timestampPrecisionsWarned is still shared between the two branches; minor).
• TimestampTz // Is this right for negative timestamps? TODO + Rustdoc copy-paste — gone (the methods were removed; if/when they come back, please don't reintroduce the bug).
• TZ section docs typos / heading — fixed.
• Non-actionable cast error — only partially: type name corrected to TIMESTAMP WITH TIME ZONE, but still no format hint as PR_REVIEW_RULES.md asks (see inline).
• Magic-number Objects.hash(..., 14) — number changed to 16, still a bare magic constant (see inline).

Still open / not addressed

• Test coverage. Same two integration tests as before (issue4146, issue4146a). Your own description still says "I need to implement many more tests - at least one for each function". This is the headline blocker for the PR.
• Plain-TIMESTAMP doc typos data time / asssumed (datetime.md L196-197) — flagged previously to fix in the same PR; still present.
• Stray rhetorical // Why is this missing fractions of second? comment in serde_config.rs:204.

New issues introduced by this force-push

• cast_to_TimestampTz_s now uses only DateTime::parse_from_rfc3339. That's a regression: the previous version at least accepted YYYY-MM-DD HH:MM:SS[.f] and YYYY-MM-DD. RFC3339 also doesn't accept IANA zone names, even though both the docs and DBSPTimestampTzLiteral advertise IANA support. Net effect: literals accept '2020-01-01 10:10:10 America/New_York' but CAST('2020-01-01 10:10:10 America/New_York' AS TIMESTAMP WITH TIME ZONE) will now fail at runtime.
• python/tests/runtime_aggtest/aggregate_tests2/test_timestamp_tbl.py — the new TZ test data is broken in three ways (syntax error + two malformed strings). See inline; this file won't even import.
• DBSPTimestampTzLiteral.getMicros has a negative-modulo footgun (see inline) — pre-1970 TZ literals will throw from LocalDateTime.ofEpochSecond because nanoOfSecond must be non-negative.

Keeping verdict at REQUEST_CHANGES until the test coverage gap and the regressed cast/python paths are addressed.

From pipeline-manager perspective, it's a new type added to the OpenAPI schema, that part looks good.

For the connectors: the input and output format of this new data type is still MicrosSinceEpoch, so an integer. When would one use TIMESTAMP instead of TIMESTAMP WITH TIME ZONE, and vice versa? It seems they are effectively the same in terms of the queries you can do on them (e.g., it's no possible to query "give me all the tuples with the timestamp in time zone +01:00" or so)?

Big blockers from my prior two reviews are addressed: IANA zones now parse, the error message is actionable with the expected format, getMaxValue() is back to 6 fractional digits, DBSPTimestampTzLiteral.getMicros uses Math.floorDiv/Math.floorMod (no more negative-modulo footgun), the broken test_timestamp_tbl.py row is now valid Python with a clean +05:00 offset, and test coverage has expanded substantially (issue4146a with ten in-line cases, testCaseTz, testCompareTz, plus the new test_interval_*, test_cmp_operators.py, test_date_time_fn.py and TZ rows in test_timestamp_tbl.py). Approving. Two tiny leftovers inline.

I see, so this PR has to benefits:

(1) It allows us to ingest data from sources that provide a column that has timestamp+timezone as its type. Would this not already be possible by adding an extra mapping to Timestamp? Given we don't store the timezone in any case.
(2) It opens up the possibility for SQL timezone-related functions. But if we don't store the timezone in this new type, wouldn't CHAR just still be the output type for both AT TIMESTAMP and CONVERT_TIMESTAMP? Documentation: https://docs.feldera.com/sql/datetime/#convert_timezone

As the PR description is not "Add type TIMESTAMP WITH TIMEZONE as an alias for TIMESTAMP", which would be my expectation so far based on our back-and-forth. How does the type differ?

Re-reviewing only the two new commits since the 2026-05-16 approval (70d1371 + 0a3ea0a).

Calcite bump commit is trivial. The TIMESTAMP WITH TIME ZONE commit is large but mostly mechanical delegation from Timestamp -> TimestampTz, which is the right approach.

A handful of blocking issues I want fixed before this lands:

1. Operator-precedence bug in the new TIMESTAMP_TZ guard in ExpressionCompiler.makeBinaryExpression. The || binds outside the opcode.isComparison() guard, so non-comparison ops between a non-TZ left and a TZ right (or the reverse) also hit this branch with the misleading 'comparison-only' message. testCompareTz happens not to exercise this path because Calcite already rejects the subtraction at type validation.

2. New Variant::TimestampTz is added to the variant enum, but golden_row_variant is still a Tup25 covering exactly the pre-existing 25 variants. The whole point of bumping storage-test-compat is to catch rkyv-layout changes; without TimestampTz in the golden tuple, the new variant arm is not exercised by the storage compat test at all.

3. The pre-existing aggregate test illarg_extract_abrv1_legal was renamed to date_part_abrv1_legal, and the new TZ counterpart is date_part_abrv1_legal_tz. discover_tests only registers classes whose name starts with illarg_, so both classes silently drop out of the runtime aggregate test suite. The DATE_PART abbreviation coverage (existing) and its TZ extension (new) are no longer running.

4. cast_to_TimestampTz_u64 returns an error message that says TIMESTAMP instead of TIMESTAMP WITH TIME ZONE. The macro-generated wrappers below it got the message right; this one is the odd hand-written outlier.

Also a few non-blocking nits inline (section banner, datetime.md prose, lingering magic number from the prior round, two behaviour-change footnotes worth calling out in the commit body).

Connector coverage (Avro/JSON/Parquet/Delta/datagen/adhoc) and the new visitors all look complete; adding the new Variant enum arm at the end of the enum (not the middle) is the right call for forward-compat.

One blocker still open (storage compat golden row); the other three are fixed. See inline.

Storage-compat blocker resolved. Tup26 + GoldenRowVariant properly covers all 26 variant arms including TimestampTz, new golden files added alongside existing ones (no removals), README updated. All four blockers from the 5/22 review are now fixed. Two small nits inline.