Client‑side versus Server‑side Time‑Zone Handling for Mapbox GL JS Temporal Layers

Goal: Allow map viewers to switch between time zones for temporal data displayed in Mapbox GL JS without sacrificing frame‑rate or introducing date‑offset errors.

Constraint: Performing the conversion client‑side with new Date() gives each user zone flexibility but adds per‑feature CPU work and can produce different historic offsets across browsers because each implements its own IANA database version. Pre‑converting timestamps server‑side (e.g., storing UTC strings in vector tile properties) removes the per‑frame cost but locks the map to a single zone, requiring a full tile rebuild whenever the target zone changes.

Which strategy provides the best trade‑off between dynamic user zone selection and render performance for large feature sets? How can historic offset inconsistencies be minimized when relying on client‑side Date objects?