ByteBench Guides

Timestamp and Time Zone Conversion Guide

A practical guide to converting epoch values, handling time zones, and preventing date/time bugs in production systems.

Quick answer: Store canonical UTC, convert for display at the edge, and always label timezone assumptions. Most time bugs come from mixed units and missing timezone context.

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.