Time zones and timestamps

Backends for mobile apps Junior Python 3.13+ PostgreSQL 17+ Reviewed By Best Latest Apps

Predict the output

15:30 UTC on 31 Oct 2026: what local times print?

Python 3.13
from datetime import UTC, datetime
from zoneinfo import ZoneInfo

stored = datetime(2026, 10, 31, 15, 30, tzinfo=UTC)
print(stored.astimezone(ZoneInfo("Asia/Kolkata")).strftime("%H:%M"))
print(stored.astimezone(ZoneInfo("America/New_York")).strftime("%H:%M"))

Options
Hint 1 of 1

When does US daylight time end in 2026?

Choose an answer, then open Show answer below to check it.

Show answer

Answer: A 21:00 then 11:30

Correct. India is UTC+5:30; New York is still on daylight time (UTC−4) on 31 October.

Storing UTC and converting at display time keeps one true instant. Kolkata is a fixed +5:30; New York still uses daylight time (UTC−4) on 31 October 2026 and moves to UTC−5 on 1 November.

Why not the others?
  • B 21:00 then 10:30. New York switches back to UTC−5 on 1 November 2026.
  • C 10:00 then 11:30. Kolkata is ahead of UTC.
  • D 15:30 twice. astimezone converts the instant.

30-second answer

Store instants in UTC (PostgreSQL timestamptz, which normalises to UTC), send them in ISO 8601 with an offset or Z, and convert to local time only for display on the client. Store a user's IANA time zone name (like Asia/Kolkata), not a fixed offset, when you need local rules like 'remind me at 9 AM', because offsets change with daylight saving. Future local events (a meeting at 10:00 next March) are stored as local time plus zone.

Practise saying it · 30 s. No recording, just a timer

Times across zones.

Say your answer out loud, then check which of these points you covered:

  • UTC instants, timestamptz
  • ISO 8601 with offset
  • IANA zone names
  • Future local events

Deep dive

timestamp without time zone in Postgres stores a wall-clock reading with no zone; avoid it for instants.

India has no daylight saving; New York shifts twice a year.

Some local times don't exist or happen twice on DST change days.

Server clocks should run on UTC and NTP.

One instant, two local times Ran on Python 3.13.5 · mypy --strict
Python 3.13
from datetime import UTC, datetime
from zoneinfo import ZoneInfo

stored = datetime(2026, 10, 31, 15, 30, tzinfo=UTC)
print(stored.astimezone(ZoneInfo("Asia/Kolkata")).strftime("%H:%M"))
print(stored.astimezone(ZoneInfo("America/New_York")).strftime("%H:%M"))

timestamptz normalises to UTC Ran on PostgreSQL 17.11
SQL · PostgreSQL 17
SET TIME ZONE 'UTC';
SELECT '2026-10-31 21:00+05:30'::timestamptz;

Common mistakes

  • Storing local times without a zone.
  • Storing '+05:30' instead of 'Asia/Kolkata'.
  • Formatting dates on the server in the server's zone.

Senior take & follow-ups

UTC instants with timestamptz, ISO 8601 on the wire, zone names for local rules.

Follow-up questions

Think of your answer first, then open the hint.

  1. Why store the zone name, not the offset?

    Show hint

    Offsets change with DST and law; the name carries the rules.

  2. How do you store a future 10 AM meeting?

    Show hint

    Local time plus zone; compute the instant when needed.

Suggest a fix if something here is wrong or out of date.