zoneinfo vs Fixed UTC Offset: Localhost Lab

Intro — what this post promises

Convert many datetimes with zoneinfo.ZoneInfo vs fixed datetime.timezone offsets vs naive timedelta math (stdlib only — no pytz). This lab reports conversions/s on Linux localhost.

Frame: prefer zoneinfo for real TZ rules; fixed offsets only when rules are truly fixed (e.g. always UTC+05:30). Affiliates: 0.

Related links:

• 01shoppercove.comdataclass replace vs manual localhost lab
• 02shoppercove.comheapq merge vs sorted localhost lab
• 03shoppercove.comislice vs list slice localhost lab
• 04shoppercove.comconfigparser vs json localhost lab
• 05shoppercove.comhtml escape vs manual localhost lab
• 06shoppercove.comzlib vs gzip compress localhost lab
• 07shoppercove.comdifflib vs set ops localhost lab
• 08shoppercove.commmap write vs write localhost lab

Lab honesty (1 Oct 2026 IST): Python 3.13.5. 20000 hourly stamps. Zones: UTC, Asia/Kolkata, America/New_York.

Verdict up front: astimezone(fixed IST) ~3937539 conv/s; astimezone(ZoneInfo Kolkata) ~3718035; astimezone(New_York) ~3627156; naive +05:30 ~25248859 (not a TZ conversion). DST check NY winter offset -18000.0 s vs summer -14400.0 s.

Arms

Lab topology

n=20000 timestamps · 7 rounds · p50
metric: conv/s = n / p50_s
stdlib: zoneinfo + datetime.timezone only

Script: lab-evidence/111-zoneinfo-vs-utc-offset/results/run_lab.py.

Lead table — conversions (p50 conv/s)

Fixed IST vs ZoneInfo Kolkata astimezone sit in the same band here — Kolkata has no DST, so rules collapse to a constant offset. New_York still needs zoneinfo (winter/summer offsets differ).

Attach & format

String formatting dominates once you leave pure conversion.

Storage recommendation

Store UTC aware (timezone.utc or ZoneInfo UTC), convert to ZoneInfo only at the edges (API, UI, reports). That keeps math simple and still pays zoneinfo only where humans read clocks.

Reading it

• Real civil times → ZoneInfo("Area/City").
• Truly fixed offsets (storage UTC, display +00:00) → timezone.utc / fixed timezone(timedelta(...)).
• Never use naive datetime + timedelta as a substitute for TZ rules across DST.
• pytz not required on 3.9+ for this pattern — stdlib zoneinfo is enough.

IST special case

Asia/Kolkata is a popular fixed-offset example (+05:30, no DST). Matching ZoneInfo against timezone(timedelta(hours=5, minutes=30)) is expected to be close — and it was here. That agreement must not be generalized to America/New_York or Europe/London. The NY winter/summer offset split in this lab exists specifically to catch that mistake.

Library note

Classic pytz patterns (localize / normalize) are unnecessary for new code on Python 3.9+. Stick to aware datetimes + ZoneInfo + astimezone. If you still maintain pytz call sites, migrate at the boundary rather than mixing both in one hot path.

Pitfalls

• Attaching a fixed offset to local wall times without astimezone.
• Assuming all zones are fixed like IST.
• Shipping naive-plus math into US/EU product clocks.
• Comparing attach speed to astimezone speed without labels.

Reproduce

python3 lab-evidence/111-zoneinfo-vs-utc-offset/results/run_lab.py

Evidence: summary.json, summary.txt.

Limits

One Linux box. System tzdata required for ZoneInfo. Not database TIMESTAMP WITH TIME ZONE round-trips.

Takeaway

For Kolkata, ZoneInfo ~3718035 conv/s ≈ fixed offset ~3937539. Still prefer zoneinfo so DST zones (NY winter -18000 s / summer -14400 s) stay correct — fixed offsets only when the contract is truly fixed.