Session timezone vs explicit UTC conversion for cross-regional Spark SQL timestamp aggregation

We need to normalize timestamp strings arriving from multiple regional sources into a single UTC column for cross-region aggregation, while still producing local wall-clock outputs for regional dashboards. The source Parquet files store naive timestamp strings, and downstream sinks expect both a canonical UTC value and a region-specific display value. On Spark 3.3+, from_utc_timestamp accepts IANA time-zone IDs, but it requires the input column to already be UTC; to_timestamp without an explicit zone relies on the session default, which changes behavior when the same job runs in different regions.

Setting spark.sql.session.timeZone to UTC simplifies literals and implicit parsing, but it risks silent mismatches if any upstream producer writes local-time strings without zone metadata. A UDF using java.time.Instant would give per-row control, yet it bypasses Catalyst optimizations and adds serialization overhead. We are unsure whether the implicit session-zone approach or explicit UTC conversion is the safer trade-off for this constraint, and the exact behavior should be confirmed against the Spark version in use.

Which approach should we choose for a Spark 3.3+ pipeline that must convert naive regional strings to UTC and back to local time? How do we verify that mixed timezone-aware and timezone-free DataFrames do not introduce silent data loss? Is there a documented Catalyst-safe alternative to a UDF for per-row zone conversion when the source column is not UTC?