Technical Analysis: Update our timezone code to IANA tzcode2026b

Core Problem

PostgreSQL maintains a vendored copy of the IANA timezone library (tzcode) within its source tree, used to handle timezone conversions, daylight saving time transitions, and timestamp arithmetic. This code must be periodically synchronized with upstream IANA releases to incorporate:

1. Correctness fixes — bug fixes in timezone interpretation logic
2. New timezone data compatibility — structural changes needed to parse newer tzdata releases
3. Security patches — potential issues in timezone parsing code
4. Standards compliance — updates to how the library handles edge cases per evolving IANA conventions

The IANA tzcode library is a critical dependency for PostgreSQL's timestamptz type, AT TIME ZONE expressions, and the pg_timezone_names/pg_timezone_abbrevs system views. Any drift from upstream creates risk of incorrect time computations, particularly around DST transitions and historical timezone changes.

Proposed Solution

Tom Lane is updating PostgreSQL's vendored timezone code to IANA tzcode release 2026b. This is a routine but non-trivial maintenance task that involves:

1. Merging upstream changes into src/timezone/ — PostgreSQL carries local patches on top of the IANA code (e.g., memory allocation wrappers, error handling integration with elog/ereport)
2. Resolving conflicts between PostgreSQL-specific modifications and upstream structural changes
3. Ensuring ABI/API compatibility — the internal interfaces used by PostgreSQL's datetime parsing code must remain stable
4. Testing across platforms — timezone code has platform-specific behavior around system timezone detection

The thread indicates this is at least version 2 of the patch (v2), with v1 having failed cfbot (the automated CI/CD build farm bot), suggesting non-trivial integration issues were encountered and resolved.

Key Technical Considerations

PostgreSQL's Timezone Architecture

PostgreSQL's timezone handling lives in src/timezone/ and consists of:

• pgtz.c — PostgreSQL-specific timezone identification and caching
• localtime.c — adapted from IANA localtime.c, the core conversion engine
• strftime.c — timezone-aware formatting
• zic.c — the timezone compiler (used during build)

The vendored code diverges from upstream IANA in several ways:

• Uses PostgreSQL's memory allocators (palloc/pfree) instead of malloc/free
• Integrates with PostgreSQL's error reporting system
• Removes POSIX-specific system timezone detection in favor of PostgreSQL's own timezone GUC
• May carry patches for thread safety relevant to PostgreSQL's process model

Integration Challenges

The fact that v1 failed cfbot suggests the upstream changes in tzcode2026b likely touched areas where PostgreSQL carries local modifications. Common pain points include:

• Changes to struct state or struct ttinfo layout
• New functions or removed functions that conflict with PostgreSQL's wrapper layer
• Compiler warning differences due to PostgreSQL's stricter -Wall -Werror build settings
• Platform-specific #ifdef changes that interact with PostgreSQL's configure/meson build system

Current Status

The thread shows a v2 patch has been submitted after v1 failed CI. The brevity of the message suggests this is a well-understood maintenance process where Tom Lane (as the primary maintainer of this code area) is iterating to get a clean build across all platforms.

Architectural Significance

While seemingly routine, timezone code updates are important because:

1. They must be backported to all supported branches (timezone correctness affects all versions)
2. They can expose latent bugs in datetime arithmetic
3. They affect the initdb process (which compiles timezone data)
4. Incorrectly merged code can cause silent data corruption in timestamp comparisons