A real-world example shows how a simple query stored in UTC misclassified millions in revenue by ignoring the user's local timezone.
Timestamps are defined according to the ISO 8601 standard and commonly implemented as a Unix timestamp, which counts seconds since January 1st, 1970.
A timestamp represents a single, unambiguous moment in time across the globe, while a timezone is merely a human-readable interpretation of that moment.
A scheduled job sending daily statements at 9 AM suddenly started running an hour late due to differences in daylight saving time changes between the US and Europe.
For past events, always store timestamps in UTC, but for future events, store the user's intent by saving the local time and the timezone name.
Address the "phantom hour" during spring forward and the "duplicate hour" during fallback by knowing your library's behavior and asking the user for clarification.
Use Python's timezone-aware datetime objects to avoid ambiguity and leverage third-party libraries like Luxon in JavaScript to overcome the native Date object's limitations.
Use PostgreSQL's `timestamp with time zone` type and enable Django's `USE_TZ` setting to automatically handle UTC storage and conversion to the active timezone.
Implement a middleware to activate a user's timezone based on their profile settings, a request header, or a cookie set by the browser.
Always use timezone-aware datetimes, store events in UTC while displaying in local time, and explicitly ask users for the timezone during sensitive operations.
Jobs that call for the skills explored in this talk.