ADR-0053 Phase 2 · Slice 5: timezone-aware analytics date bucketing #1982

Part of ADR-0053 Phase 2. Design: #1975 · Parent: #1928.

Slice 5 of 6 — compute-tz, highest risk (dialect). Make analytics date bucketing timezone-aware.

Decision D2 (see #1975)

Bucket in-memory (JS), uniformly; do not emit dialect-specific date_trunc … AT TIME ZONE. SQLite has no tz database and MySQL needs tz tables loaded → splitting by dialect produces different bucket boundaries for the same data (a correctness landmine the sqlite-heavy test matrix wouldn't catch).

Scope

• Swap getUTC* for the shared partsInTz util (from slice 3) in:
  • packages/services/service-analytics/src/preview-evaluator.ts:69-89 (bucketDate)
  • packages/services/service-analytics/src/dimension-labels.ts:64-87 (formatDateBucket)
• Feed the reference tz through the dataset query — the seam already exists (hard-coded 'UTC'): packages/services/service-analytics/src/dataset-executor.ts:264 and :317.
• Keep the DB-side UTC fast path when reference tz is unset or 'UTC'; still push the date-range filter to the DB, only bucket in memory when tz ≠ UTC — objectql-strategy.ts:29-52.

Acceptance criteria

• Day/week/month/quarter buckets align to the reference tz, identically on SQLite and Postgres.
• tz unset / 'UTC' → DB-side fast path, behavior unchanged.
• Test: a row near a tz day-boundary lands in the correct bucket under a non-UTC reference tz.

Depends on

Slices 1 (timezone) and 3 (shared partsInTz util).