Time zones and sensitivity

1) Basic principles

UTC as transport and storage. All server timestamps and sort keys are in UTC. Conversion to local "wall" time - at the edge (edge/UI) or in a specially dedicated formatting service.

Zone ≠ offset. 'Europe/Kyiv' is not just 'UTC + 02: 00': the rules change over time. Store IANA IDs (tzdb) in the user/object profile, not "+ 03:00."

Clear clock distinction.

Wall clock (human time, subject to DST).
UTC clock (universal scale).
Monotonic clock (for measuring durations and timeouts). Never calculate timeouts on a wall clock.
Idempotency and tolerance to time tremors. Systems must correctly survive small NTP/offset jumps.

2) Data model and API contracts

Events: 'occurred _ at' (UTC, RFC 3339), 'timezone' (IANA), optionally 'wall _ time' (local with offset at creation).
Periods: use half-closed intervals' [start, end) 'in UTC; for human-readable schedules, keep the original expression + zone.
Duplicate rules: serialize as RRULE/cron equivalent + IANA zone. Delegate planning to an engine that understands DST.
Time format in API: ISO 8601/RFC 3339 with explicit'Z 'or offset, for example' 2025-10-31T17: 00: 00Z '. Do not pass floating lines without offset.
Versioning: changing time business rules (for example, switching a country to constant UTC + 1) is the migration of configurations and recalculation of schedules; consider in the release schemas.

3) Daylight Saving Time (DST): ambiguities and omissions

Duplicated local times. In autumn, the local "02:30" can happen twice. The planner in the zone must distinguish between '2025-10-26T02: 30 + 03' and '2025-10-26T02: 30 + 02'.

Missed local times. In the spring, minute intervals "jump" (for example, '02: 00-03: 00' does not exist). The planner must determine the strategy: move to '03:00', skip or execute "as soon as possible."

Recommendation: store the job as a "local rule + zone," and materialize the actual instances in UTC in advance (rolling window), fixing the selected policy on the DST.

4) Leap seconds и time smear

Leap second. An extra second is sometimes inserted in UTC. Most business processes should not "see" 23:59:60.
Smear. Some environments gently distribute the adjustment per window (for example, ± 12 hours) to avoid a jump.
Practice: agree on a single time policy for the entire cluster (NTP/smir), log it in metadata and keep it in the runbook.

5) Planners and cron patterns

Danger of "simple cron." Classic cron does not know DST and IANA zones. Use engines where the schedule is zone-bound (Quartz class, cloud Scheduler services, Kubernetes CronJob with zone via controller/administration).
Materializing schedules. For reliability, materialize the next N runs in UTC (for example, for 7-30 days), store cursor and determine the policy at DST.
Idempotency of tasks. Ключ deduplication: `(job_id, scheduled_at_utc)`; restarting should not duplicate side effects.
Clock slip. For long pauses/incidents, decide whether to catch-up or skip. Configure per-job.

6) Time in protocols and queues

Event buses (Kafka/Pulsar). Store 'event _ time' and 'ingest _ time' separately. Use 'event _ time' for retrospective allocations.
Idempotent consumers. When redelivering, focus on the event key and 'event _ time' rather than the offset in the batch.
Sorting and windows. Calculate the "24 hours local store time" windows as UTC intervals obtained from the local rules of a specific zone for a specific date.

7) Logs, traces, metrics

Unified time zone standard: all technical logs and metrics in UTC (indicating 'Z'). Display in dashboards - localized for the user.
Trace - Pass' trace _ start _ utc ',' duration _ ms' on a monotonic clock. Never subtract "wall" timestamps.
Business reports: Form a "day" in the domain zone (e.g. 'Europe/Paris' for French tax) rather than UTC. Document clearly.

8) User profiles and content

Профиль: `preferred_timezone` (IANA), `preferred_locale`, `currency`, `week_start` (Mon/Sun).
Multi-zone entities: for teams/organizations, store a "domain zone" (for example, a store/legal entity) regardless of the participant's personal zone.
Notifications: calculate "quiet hours" in the user zone; send from UTC window, with DST security.

9) Anti-patterns

Store only local time without offset/zone.
Hard flash offset '+ hh: mm' instead of IANA identifier.
Calculate the duration through the difference of two "wall" timestamps.
Plan by cron without zone/DST support.
Do analytics "day by day" in UTC, when the standard requires a local zone.
Assume the invariability of the rules of the zone (countries change the policy of time).

10) Time testing

Controlled hours. Inject the "clock" into the code (Clock/TimeProvider) for deterministic tests.

• Daylight saving time (dubs/skips) changes.
• Move the user between zones (change 'preferred _ timezone').
• Rule change in tzdb (base update - regression tests).
• NTP offsets, delayed delivery of events.
• Fuzzy tests. Random zones, dates, formats; comparison with a reference library.

11) Observability and operation

Alerts: NTP misalignment, tzdb update lag, bursts of "unfulfilled" cron tasks with DST.
Dashboards: distribution of events by zones/local days; catch-up/skip counters.
Runbook: procedures for changing time rules in a jurisdiction; tzdb update order communicating with schedule owners.

12) Implementation patterns

Time Normalization Gateway. A subtle service that normalizes incoming times to RFC 3339 UTC, validates zones (IANA) and complements the context.
Local-Day Builder. A library/service that builds exact UTC boundaries' [start _ utc, end_utc) 'from the "local day" and zone, taking into account DST.
Schedule Materializer. A scheduler that stores rules as a "local expression + zone" materializes future instances in UTC and manages collisions/omissions.
Dual-Timestamp Events. Events with fields' occurred _ at _ utc ',' wall _ time _ local ',' timezone '. Local is substituted for UI, UTC for systems.

13) Architect checklist

1. Is UTC stored everywhere?
2. Does the entity have an IANA zone and a domain data policy?
3. Does the scheduler understand DST and materialize instances in UTC?
4. Logs/metrics - in UTC; reports - in domain zone?
5. Timeouts/retreats - on a monotonic watch?
6. Is the tzdb update automated and monitored?
7. Tests cover rule changes, doubles/missed minutes?

14) Mini recipes (pseudocode)

Convert local "workday" to UTC interval

function localDayToUtcInterval(dateLocal, tz):
startLocal = combine(dateLocal, 00:00) in tz endLocal  = startLocal + 1 day startUtc  = toUTC(startLocal) // учитывает DST endUtc   = toUTC(endLocal)
return [startUtc, endUtc)

Materializing a Recurring Schedule

inputs: rrule, tz, windowStartUtc, windowEndUtc for each localOccurrence in expand(rrule, tz, [windowStartUtc, windowEndUtc] projected to tz):
emit occurrence { scheduled_at_utc = toUTC(localOccurrence), tz }

Idempotent task start key

dedupe_key = hash(job_id + scheduled_at_utc.toString())

15) Safety and compliance

Audit: Keep both time projections (UTC and local) to reconcile user claims ("I was promised before 11pm Lima") with server chronology.
Regulatory: reporting periods are formed in the required zones (taxes, responsible game limits, marketing restrictions "by the hour").
Privacy: time zone - personal settings, but not accurately identifying data; Process within common privacy policies.

Conclusion

"Time sensitivity" is not about the date format, but about the architectural boundaries of responsibility: where to store, where to transform, how to plan and how to prove correctness. UTC unification, explicit IANA zones, competent schedulers, dual timestamps and monotonic clocks turn time from a source of incidents into a predictable infrastructure service.

• GeoDNS and geo-routing; Load balancing; Observability of events over time; Cron patterns and schedule materialization; Regional restrictions and local reporting days.