UTC-aligned metric buckets vs client-side re-bucketing for local calendar day rollups

Context

Dynatrace stores all metrics in UTC and computes aggregation buckets on UTC day boundaries. The web UI displays those buckets in the browser's local time zone, but the underlying bucket edges do not shift for daylight saving transitions. Automated consumers (API scripts, alerting pipelines, scheduled reports) must therefore decide whether to accept UTC-aligned daily rollups or reconstruct local calendar day rollups client-side.

Constraint

The Metrics API v2 offers no parameter to request buckets aligned to a specific IANA time zone or to a DST-adjusted local day. A "daily" aggregation always returns 24-hour UTC buckets. Near a DST transition, a local calendar day spans 23 or 25 hours, so a single local day maps to two partial UTC buckets, and two adjacent local days can share the same UTC bucket edge.

Trade-off

• Option A — Use native UTC buckets: Simpler queries, consistent granularity, no client-side computation. Dashboards and alerts show "day" boundaries that drift relative to local midnight.
• Option B — Re-bucket client-side: Fetch finer-grained data (hourly or 5-minute) and aggregate into local calendar days using an IANA zone database. Handles DST correctly but increases payload size, latency, and implementation complexity.

Which approach do you adopt for cross-region daily SLO reporting, and how do you validate correctness at DST boundaries?