Use IANA time zone names, not abbreviations or fixed offsets, for local times

The problem with offsets and abbreviations

A UTC offset such as -03:00 describes one instant's relationship to UTC, not a place. Governments change offsets and daylight-saving rules, sometimes with little notice, so the same city can have different offsets in different years. Abbreviations are worse: the tz project notes that they are ambiguous in practice (for example, CST is used both in North America and in China).

The IANA Time Zone Database

The Time Zone Database (also called tz or zoneinfo), hosted by IANA, contains code and data describing the history of local time for many representative locations. Zones are named Area/Location, e.g. America/Sao_Paulo, Europe/Lisbon, Asia/Tokyo. Operating systems and language runtimes ship copies of it and update them when releases come out. Maintenance procedures are defined in RFC 6557 (BCP 175), which assigns decisions to a TZ Coordinator.

Practical rules

• Past instants (logs, events that already happened): store in UTC, e.g. 2026-10-21T14:30:00Z.
• Future local appointments ("09:00 in São Paulo on 2027-03-10"): store the local date-time and the IANA zone name, and compute the UTC instant when needed. Rules may change before the date arrives.
• Display: convert from UTC using the viewer's IANA zone.
• Keep the tz data in your systems up to date.

As an example of change, the IANA page consulted for this record listed release 2026e (2026-09-29) and noted Manitoba moving to permanent UTC-05 on 2026-10-31.

Limits and caveats

• The tz project itself says most pre-1970 entries come from unreliable sources; it focuses on agreement of clocks since 1970.
• Zone names identify regions whose clocks have agreed since 1970, not countries or political borders.
• An outdated tz copy silently produces wrong local times after a rule change.