Time zone handling (IANA tzdb)
Store real instants in UTC, then show them in a named zone like Asia/Kolkata so daylight saving and historical offset rules stay correct.
What it is
Time zone handling means separating an instant from the civil clock used to display it. Store an event that already happened as a UTC timestamp, then render it in the user's IANA zone, such as 'Asia/Kolkata' or 'America/New_York'. Those names point into the IANA time zone database, which contains historical and current offset rules, including daylight saving transitions.
Reach for a named zone whenever humans schedule, compare, or revisit times across regions. A fixed offset such as UTC-5 is not New York: it cannot tell you when daylight saving starts, what the offset was years ago, or what rule applies to a future date. Political edits land in tzdb several times a year, and they can be drastic: Samoa jumped the international date line at the end of 2011, so 30 December 2011 never existed there. Format at the UI boundary with Intl.DateTimeFormat and its timeZone option.
Gotcha: future local schedules are not instants yet. 'Every Tuesday at 09:00 Europe/Paris' must keep the local time, recurrence rule, and zone so each occurrence can be resolved under the rules for that date. Clock changes also create local times that occur twice or never occur, so the product needs an explicit policy instead of silently guessing.
Ask AI for it
Audit this app's time handling. Store completed events as ISO 8601 UTC instants, store each user's zone as an IANA tzdb name, and render with Intl.DateTimeFormat using its timeZone option and the active locale. Reject abbreviations such as EST and fixed offsets as saved zone IDs. For future recurring events, persist the local date and time, IANA zone, and recurrence rule, then resolve each occurrence separately. Add tests covering a skipped spring-forward time, a repeated fall-back time, Asia/Kolkata's non-hour offset, and a user viewing an event from a different zone.