PostgreSQL governance includes historical timestamp compatibility

A database can preserve a stored timestamp while changing the local time that it displays. That distinction gives an otherwise brief governance report a concrete engineering subject. The PostgreSQL Core Team considered changes to historical time-zone data during 2022 and chose to continue distributing the standard tzdata build after examining what major operating systems were doing. The choice concerns how applications interpret old records, even though the report itself contains no new SQL feature.

The January 23 announcement introduces the annual report as a way to make Core Team activity visible to the community. Its report covering January through December 2022 names time-zone compatibility alongside conduct policy, the impact of the war in Ukraine, and trademark disputes. These subjects have different technical consequences, but each requires a project decision beyond accepting an individual patch.

I default to PostgreSQL for relational work partly because its behavior is documented well enough to reason about. This report makes another part of that preference explicit. Compatibility depends on decisions about external data and project policy as well as the implementation of transactions.

Stored instants and displayed civil time

The PostgreSQL 15 date and time documentation explains the distinction behind the report. A timestamp with time zone value represents an instant stored internally in UTC. PostgreSQL does not preserve the original named time zone with that value. When it displays the timestamp, it converts the instant into the session time zone.

A named zone supplies rules that can vary with the date. A fixed numeric offset supplies only an offset. Historical changes to those named-zone rules can therefore change the local representation of an existing instant without changing the instant itself. A comparison of stored instants and a comparison of formatted civil times are asking different questions.

The distinction also affects input. PostgreSQL converts an explicitly zoned timestamp into UTC using the applicable offset. When input omits the zone, the session TimeZone setting supplies the interpretation. The documentation describes that conversion separately from timestamp without time zone, which ignores a time-zone indication and retains the date and time fields.

That behavior matters when an application treats a textual timestamp as an audit artifact. Recreating the local representation later requires the relevant conversion rules as well as the stored instant. A requirement to reproduce an original display cannot be inferred from the choice of timestamptz alone. The type deliberately does not retain all the original input information.

Why the data distribution became a project decision

The Core Team report says PostgreSQL includes tzdata so that it works on systems without their own copy. That distribution decision gives the project responsibility for a dependency that influences observable SQL results. The report identifies changes in the upstream data during 2022 that affected historical timestamp display and says there were different options for preserving compatibility.

Its account is specific about the outcome and limited about the deliberation. The Core Team evaluated major operating-system behavior and continued with the standard build. It does not promise that every historical local timestamp will retain an identical representation. Nor does it identify an alternative build as the new PostgreSQL default. Those distinctions prevent a short governance entry from becoming a stronger compatibility claim than its authors made.

Following the standard data build has a practical rationale. PostgreSQL applications often exchange timestamps with software outside the database, so a private interpretation of civil-time history would create another source of disagreement. That is an engineering consequence of the decision, rather than an additional explanation attributed to the Core Team. The report itself records the operating-system comparison without publishing a detailed decision transcript.

My preference is for that reasoning to remain inspectable. An unchanged SQL interface can still produce changed output when reference data changes, and operators need an account of who chooses the dependency policy.

The limits of the public report

The annual report explicitly allows some activities to remain confidential for privacy and other reasons. Its entry about the war in Ukraine says the Core Team handled several situations related to the war and its impact on the project. It does not describe those situations. There is no basis here for assigning particular infrastructure changes or contributor restrictions to that work.

The conduct-policy entry is similarly bounded. It records acceptance of changes clarifying term limits. It does not present a general rewrite of the Code of Conduct or describe individual complaints. Reporting a policy change without identifying private cases preserves a distinction between explaining governance and exposing the people involved.

Trademark responsibility has a named delegate. The Core Team delegates trademark management to the PostgreSQL Community Association of Canada. The report says that association, and in some cases PostgreSQL Europe, are engaged in disputes that remain ongoing when the report is written. It records responsibility and status without claiming a legal resolution.

These limits are useful information for readers of the annual report. The document establishes which decisions received Core Team attention and where another organization acts on the project's behalf. For timestamp compatibility in particular, it provides a public record that the standard tzdata build remains the distribution choice after an explicit review of compatibility alternatives.