ENGINEERING NOTE 23 / 50 · SMS
Keep SMS daily reports consistent across time zones
Store event timestamps in UTC and choose an explicit reporting timezone. Never mix local-day order counts with UTC-day receipts without explaining the boundary.
Published by OPEN RAMBO. The engineering patterns and pseudocode illustrate designs, not a documented product API. Numerical examples are illustrative.
Use half-open windows
Define a day as start inclusive and next start exclusive. This avoids double counting events exactly at midnight. Compute boundaries with a timezone-aware library; some regions change their UTC offset during the year.
Choose cohort or event reporting
A creation-cohort report follows orders created that day until they mature. An event report counts receipts occurring that day, including older orders. Both are useful, but their numerators and denominators cannot be exchanged casually.
Show late arrivals
A delayed callback may revise yesterday’s event report. Keep generated_at and an as-of cutoff so readers know whether a report is provisional. Do not repeatedly overwrite historical totals without recording that the data matured.
Illustrative implementation
window = {"start_inclusive": start_utc, "end_exclusive": end_utc}
query = {"created_at": {"$gte": start_utc, "$lt": end_utc}}Acceptance check
Test events one millisecond before, at and after the boundary. Confirm each event belongs to exactly one daily bucket.