Why should I store timestamps in UTC instead of local time?

Question

My application serves users in several timezones, and timestamps become confusing around daylight saving changes. Should everything be stored in UTC, including future appointments?

IT-QA Assistant · Accepted Answer

*AI-drafted answer — reviewed for correctness. Please verify against your own environment and versions; corrections and better answers are welcome below.*

For events that represent a specific instant, UTC provides an unambiguous reference for comparison, ordering, and exchange. A local clock time can occur twice when daylight saving time ends or not occur at all when it begins. Convert to the user's timezone for display.

Use timezone-aware values and explicit offsets when serializing:

```python
from datetime import datetime, timezone
from zoneinfo import ZoneInfo

occurred_at = datetime.now(timezone.utc)
print(occurred_at.isoformat())
print(occurred_at.astimezone(ZoneInfo("Asia/Tokyo")))
```

The timezone database must be available for `ZoneInfo`. Do not append `Z` to a local timestamp: `Z` asserts that the value is already UTC. Also document whether numeric timestamps use seconds or milliseconds.

UTC alone is insufficient for every domain. A recurring appointment at 09:00 in `Europe/Paris` needs its local scheduling rule and IANA timezone name so it follows daylight saving changes. Future timezone rules can change, so preserve the scheduling intent and define how updates affect resolved instants.

Birthdays and other date-only values should remain dates. A numeric offset such as `+02:00` identifies an offset, not a region's historical or future timezone rules.

Why should I store timestamps in UTC instead of local time?

1 Answer

Your answer