Canonical storage and display
Use UTC as your source of truth in storage and APIs. Convert only when rendering for users or region-specific operations.
Mixing local time in persistence layers creates hard-to-debug inconsistencies.
- Persist UTC timestamps.
- Convert to local zones in UI or reports.
- Always label displayed time zone.
Seconds vs milliseconds
Epoch unit mismatches are a top cause of time bugs. One incorrect assumption can shift dates by decades.
Confirm whether every system expects seconds or milliseconds before parsing or serializing.
- Validate unit conventions per API.
- Use explicit variable names with units.
- Add tests for boundary dates.
DST and scheduling safety
Daylight saving transitions can skip or repeat local times. Scheduled jobs and notifications need explicit policy handling.
When in doubt, evaluate schedules in UTC and then map to user-facing local times.
- Review schedules around DST cutovers.
- Avoid ambiguous local timestamps in logs.
- Document timezone policy in runbooks.
FAQ
Should backend APIs return UTC or local time?
UTC is safer for APIs. Convert to local time in clients or presentation layers.
How do I know if a number is epoch seconds or milliseconds?
Use magnitude checks and API documentation. Values around 10 digits are usually seconds, and 13 digits are usually milliseconds.
Why do cron jobs run at unexpected local times?
Cron scheduling depends on configured timezone and DST behavior. Verify scheduler timezone settings and test around DST changes.