Time handling is notoriously tricky in software development. Following established best practices helps avoid common bugs and user confusion.
Golden Rules
Always store timestamps in UTC. Display times converted to the users local time zone. Use established libraries rather than parsing time manually. Be especially careful around DST transitions, which create edge cases where days have 23 or 25 hours.
Time Representations
Unix timestamps (seconds since Jan 1, 1970 UTC) are language-agnostic, timezone-independent, and sortable. ISO 8601 format (2024-01-15T14:30:45Z) is human-readable, widely supported, and also sortable as strings. Both are good choices for storage and data exchange.
Common Pitfalls
Dont assume 24-hour days (DST creates 23 and 25 hour days). Dont store local time without timezone context. Dont hardcode offsets (UTC-5 is EST in winter but EDT in summer). Watch for "today" ambiguity since midnight varies by timezone.
Best Practices by Use Case
For past events, store UTC and convert for display. For scheduled future events, store local time plus timezone identifier (dont convert to UTC since DST rules may change). For recurring events, store wall-clock time plus timezone plus recurrence rule, handling DST transitions explicitly.