The IANA Time Zone Database, known as tzdata, is the global standard for time zone information. Every operating system, programming language, and database relies on it to convert between local times and UTC. In 2026, the database received two releases: 2026a in January and 2026b in April. The 2026b release fixes bugs in the zic compiler and updates rules for British Columbia.

If you build software that handles dates and times, understanding how tzdata works and when it changes can save you from subtle bugs that only appear on specific dates in specific regions.

What is in the 2026b release

The 2026b release, announced on the IANA tz mailing list, includes several changes. The zic compiler, which converts tzdata source files into binary timezone files, had several overflow bugs fixed. These bugs could cause incorrect timezone files to be generated in edge cases involving very early historical dates.

More practically, the release includes updated rules for British Columbia, Canada. The province has been working on legislation to move to permanent daylight saving time, pending coordination with US states. The tzdata update reflects the latest regulatory status, even though the actual change has not yet taken effect.

The release also includes minor corrections to historical time zone data for a few regions, based on new research into local timekeeping practices from the 19th and early 20th centuries.

How tzdata updates propagate

When IANA releases a new tzdata version, it does not automatically reach your devices. The update travels through a chain of distributors, and each link in the chain takes time.

• IANA publishes the source files and compiled data on their server. This is the canonical source.
• Linux distributions (Ubuntu, Debian, Fedora, Alpine) package the update and ship it through their package managers. This typically takes 1 to 4 weeks.
• Apple and Microsoft bundle tzdata updates into their OS updates. These can take weeks to months, depending on the release cycle.
• Programming language runtimes (Java, Python, Node.js) often bundle their own copy of tzdata. Updating the runtime updates the data, but older runtime versions keep the old data.
• Databases like PostgreSQL and MySQL often have their own tzdata. Postgres, for example, stores timezone files in its data directory and requires a manual update or a package upgrade.
• Cloud providers (AWS, Google Cloud, Azure) update their VM images, but running instances need manual updates or a restart.

How a time zone change can break your app

Consider a real-world scenario. A medical scheduling system in British Columbia stores appointment times in UTC. A patient is scheduled for 10:00 AM local time on November 10, 2026. The system converts this to UTC using the current tzdata, which says BC observes DST until the first Sunday of November.

Now suppose BC passes legislation to extend DST by two weeks. IANA releases a tzdata update. The server gets updated. But the appointment was stored using the old UTC offset. When the system converts the stored UTC time back to local time using the new tzdata, it shows 9:00 AM instead of 10:00 AM. The patient shows up an hour early.

This is not a hypothetical. A similar issue was documented in 2025 when a time zone change in a region caused Postgres to display timestamps differently after a tzdata update. The root cause was that the application stored UTC timestamps without recording which time zone rules were used to convert them.

Best practices for time zone handling

• Store timestamps in UTC in your database. Always. No exceptions.
• When displaying times to users, convert from UTC to the user's local time zone at display time using the latest tzdata.
• If you need to record what the user saw, also store the time zone identifier (like America/Vancouver) alongside the UTC timestamp. This lets you reconstruct the original display even if tzdata changes.
• Never store local times without a time zone identifier. A timestamp like '2026-11-10 10:00:00' is ambiguous without knowing whether it was DST or standard time.
• Use IANA time zone identifiers (America/New_York, Europe/London), not abbreviations (EST, GMT) or numeric offsets (+05:00). Abbreviations are ambiguous, and offsets change with DST.
• Keep your tzdata up to date. Subscribe to the tz-announce mailing list to get notified of new releases.

Why IANA time zones, not just offsets

A common mistake in software development is storing a UTC offset instead of a time zone identifier. The offset for New York is UTC-5 in winter and UTC-4 in summer. If you store UTC-5, you cannot correctly convert times during DST months.

IANA time zone identifiers encode the full history of DST rules, offset changes, and political decisions for each region. America/New_York knows that New York observed DST from March to November since 2007, and before that from April to October. It knows the exact transition dates for every year. A simple offset cannot do this.

This is why the World Clock on this site uses IANA identifiers through the browser's Intl API. When you select New York, the clock reads the America/New_York rules from your operating system's tzdata and applies the correct offset for the current date, including DST.

The volunteer problem

The IANA Time Zone Database is maintained by a small group of volunteers led by Paul Eggert. They track time zone changes announced by governments worldwide, verify the details, and publish updates. When a country changes its DST rules with little notice, the volunteers work quickly to get the update out.

This system works, but it is fragile. The database depends on a few dedicated people. If a government announces a time zone change and the volunteers do not learn about it in time, the update may arrive after the change takes effect, causing temporary inaccuracies in systems that have not yet updated.

Despite this, tzdata remains the most reliable and widely used time zone database in the world. Every major operating system, programming language, and database depends on it. The 2026b release continues the tradition of keeping the world's clocks in sync.