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

Question

ContextDynatrace 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.ConstraintThe 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-offOption 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?

Tasadduq Burney · Answer

Adopted approach
Use Option A, native UTC buckets, as the authoritative rollup for cross-region SLO alerting. Use Option B, client-side re-bucketing, only for reports whose SLO is explicitly defined as a local calendar day in a named IANA time zone. A common 86,400-second window makes regions comparable; local-day re-bucketing changes the window length at DST and makes a New York day and a London day overlap rather than align.
Behavior described in the question

Metrics API v2 daily aggregation returns fixed 24-hour UTC buckets.
The API has no parameter for IANA-zone-aligned or DST-adjusted daily buckets.
Near a DST transition, a local calendar day is 23 or 25 hours and can map to two partial UTC buckets.

Likely explanation
The UI may relabel a bucket timestamp for the browser zone, but the underlying edge does not move. Treating every UTC bucket as one local day silently misattributes events near spring-forward and fall-back. The error is an attribution or off-by-one problem, not missing data.
Steps for this case

Confirm the SLO definition: local calendar day in which IANA zones, or rolling UTC 24-hour day. This detail changes the recommendation.
For rolling UTC SLOs, query daily granularity with UTC start and end times, label buckets as UTC, and alert on consecutive windows. Do not shift edges for local display.
For local-calendar-day SLOs, first verify that the metric family supports hourly or 5-minute granularity using a read-only metadata call. Example: curl -s -H 'Authorization: Api-Token $DT_TOKEN' 'https://$DT_ENV.live.dynatrace.com/api/v2/metrics/metricMetadata?metricSelector=builtin:example.metric' If finer granularity is unsupported, Option B is not feasible for that metric.
Fetch the finest supported granularity for a 48-hour window around each DST transition, convert timestamps to the target IANA zone, and aggregate by local calendar date using overlap-weighted seconds.
Recompute the SLO numerator and denominator from local-day aggregates and compare with UTC rollups for adjacent non-DST weeks. Divergence should appear only near transitions.

DST boundary validation

CaseExpected local-day lengthUTC bucket impact

Spring forward23 hoursOne local day spans two UTC buckets; a wall-clock hour is skipped
Fall back25 hoursOne local day spans two UTC buckets; one wall-clock hour is repeated
Non-transition24 hoursAligns with one UTC bucket only if the zone offset matches UTC; otherwise it still spans two UTC buckets

For each zone, compare bucket counts and sums for the 48-hour window straddling a known transition against expected local-day totals. Investigate any missing hour, repeated hour, or off-by-one day before promoting the report.
Assumptions and uncertainty

Assumes the described Metrics API v2 behavior is current: fixed UTC daily buckets and no zone parameter.
Uncertain: whether your SLO is defined by local calendar day or rolling UTC day, and which IANA zones are in scope. Provide that detail to finalize Option A versus Option B.
Unverified: finer granularity availability varies by metric family; confirm before relying on client-side re-bucketing.

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

Context

Constraint

Trade-off

1 answer

Adopted approach

Behavior described in the question

Likely explanation

Steps for this case

DST boundary validation

Assumptions and uncertainty

Your perspective belongs here.

0 question comments

Case	Expected local-day length	UTC bucket impact
Spring forward	23 hours	One local day spans two UTC buckets; a wall-clock hour is skipped
Fall back	25 hours	One local day spans two UTC buckets; one wall-clock hour is repeated
Non-transition	24 hours	Aligns with one UTC bucket only if the zone offset matches UTC; otherwise it still spans two UTC buckets