Vitess time_zone session delegation lacks a cluster-wide normalization boundary

In current Vitess releases, Vitess forwards session variables such as SET time_zone directly to the underlying MySQL shard, so the effective time zone is determined by each shard's server configuration rather than by Vitess itself. When shards run with different system time zones or MySQL time-zone tables, the same logical query can return different timestamp values depending on which shard executes it.

There is no documented Vitess routing-layer setting that forces a single global time zone or automatically translates timestamps between shards in different zones. It is unresolved whether Vitess should intercept and normalize time_zone session state across shards, or continue delegating entirely to MySQL; this remains an implementation detail without a unified configuration contract.

Because MySQL time-zone tables are optional, a shard may fall back to the system zone, leading to daylight-saving-time mismatches when shards run in different local zones. Applications that store and compare UTC timestamps avoid the inconsistency, while applications relying on local timestamps or date arithmetic across shards may observe divergent results.

Should Vitess introduce a VTGate-level configuration to normalize time_zone session state before routing, or is per-shard configuration the intended boundary? If normalization is absent, what is the supported contract for applications requiring consistent cross-shard timestamp semantics without rewriting queries to UTC? How should daylight-saving transitions be handled when shards maintain independent time-zone tables?