Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Subject: 
 =?utf-8?q?BUG_=2319677=3A_Silent_int64=E2=86=92int32_Truncation_in_timestamp=5Fizone=28=29_Produces_Wrong_Timestamps?=
To: pgsql-bugs@lists.postgresql.org
From: PG Bug reporting form <noreply@postgresql.org>
Cc: 1950233439@qq.com
Reply-To: 1950233439@qq.com, pgsql-bugs@lists.postgresql.org
Date: Mon, 07 Sep 2026 14:19:49 +0000
Message-ID: <19677-0c8e10df414db679@postgresql.org>
Auto-Submitted: auto-generated
Archived-At: 
 <https://www.postgresql.org/message-id/19677-0c8e10df414db679%40postgresql.org>
Precedence: bulk

The following bug has been logged on the website:

Bug reference:      19677
Logged by:          Tianyu Shi
Email address:      1950233439@qq.com
PostgreSQL version: 19beta3
Operating system:   Ubuntu22.04
Description:       =20

### Summary

In `src/backend/utils/adt/timestamp.c`, `timestamp_izone()` (line 6443) and
`timestamptz_izone()` (line 6712) assign `zone->time / USECS_PER_SEC` =E2=
=80=94 a
64-bit value =E2=80=94 directly into a 32-bit `int tz` with no range check.=
 When the
interval argument exceeds ~596,523 hours, the second count surpasses
INT32_MAX (2,147,483,647), high bits are silently discarded, and the offset
sign flips. The corrupted offset is passed to `dt2local()`, causing `AT TIME
ZONE` to return a timestamp over 136 years wrong with no error, enabling
forgery of audit log timestamps and bypass of time-based application
security policies.

### PoC

No superuser required; any authenticated user can trigger this with a single
SELECT.

```sql
-- 596524 * 3600 =3D 2,147,486,400 seconds > INT32_MAX; the int32 wrap flips
the offset sign.
SELECT
    '2024-01-01 00:00:00'::timestamp AT TIME ZONE '596524 hours'::interval
AS actual_result,
    TIMESTAMP '2024-01-01 00:00:00' - INTERVAL '596524 hours'             AS
expected_result,
    (  '2024-01-01 00:00:00'::timestamp AT TIME ZONE '596524
hours'::interval
     - (TIMESTAMP '2024-01-01 00:00:00' - INTERVAL '596524 hours')
    )
AS difference;
```

### Result

Expected: `1955-12-13 20:00:00` (2024-01-01 shifted back 596,524 hours).
Actual:   `2092-01-19 10:28:16+08` (shifted *forward* ~68 years instead).
Difference: `49710 days 13:58:16` (~136 years off); no error is raised.

Key output from verification:

```
 596524 hours (overflow) | 2092-01-19 10:28:16+08 | 1955-12-13 20:00:00 |
MISMATCH - truncation bug confirmed
```

Root cause: `2147486400 mod 2^32 - 2^32 =3D -2147480896` =E2=80=94 the posi=
tive offset
wraps to a large negative value, inverting the shift direction entirely
while `IS_VALID_TIMESTAMP` passes the in-range result silently.