Skip to content

Fix MAX_TIMESTAMP calculation in non-UTC timezones (#1159) - #1407

Open
Rajpal14 wants to merge 1 commit into
arrow-py:masterfrom
Rajpal14:fix/normalize-timestamp-large-values
Open

Rajpal14 wants to merge 1 commit into
arrow-py:masterfrom
Rajpal14:fix/normalize-timestamp-large-values

Conversation

@Rajpal14

@Rajpal14 Rajpal14 commented Nov 9, 2026

Copy link
Copy Markdown

Problem

Fixes #1159.

In arrow/constants.py, _MAX_TIMESTAMP was computed using naive datetime.max.timestamp().
When run on systems located in timezones east of UTC (such as Asia/Kolkata or Europe/Berlin), datetime.max.timestamp() converts to local time and raises:

ValueError: year 10000 is out of range

This caused the exception handler to trigger the 64-bit fallback (year 3000 timestamp 32503746600.0). Consequently, valid large timestamps like year 9999-12-31 (253402214400.0) were misidentified as millisecond timestamps in normalize_timestamp() and erroneously divided by 1000, converting year 9999 into year 1978.

Solution

  • Updated constants.py to compute _MAX_TIMESTAMP using datetime.max.replace(tzinfo=timezone.utc).timestamp(). This prevents timezone shifts past year 9999 and gives the true POSIX maximum timestamp platform-independently.
  • Also added tzinfo=timezone.utc to the fallback expressions for consistency.
  • Added a regression test in tests/test_util.py ensuring normalize_timestamp() preserves year 9999 timestamps without dividing by 1000.

Verification

  • Run full pytest test suite (1904 passed, 99.93% coverage).
  • Verified roundtrip: arrow.get('9999-12-31').timestamp() reconstructed via arrow.get() successfully returns 9999-12-31.

Copilot AI balanced review requested due to automatic review settings November 9, 2026 19:31

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota. Try requesting a review at a lower effort level.

@codecov

codecov Bot commented Nov 9, 2026 •

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (2224255) to head (acf2c99).
✅ All tests successful. No failed tests found.

Additional details and impacted files
@@            Coverage Diff            @@
##            master     #1407   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           10        10           
  Lines         2315      2315           
  Branches       358       358           
=========================================
  Hits          2315      2315           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

datetime.max.timestamp() raises a ValueError or OverflowError when run
in timezones east of UTC (e.g. Asia/Kolkata, Europe/Berlin) because the
local time maps to year 10000. This caused the fallback to year 3000
timestamp to trigger prematurely on 64-bit systems, which broke
normalize_timestamp() for valid large timestamps (like year 9999).

Using datetime.max.replace(tzinfo=timezone.utc).timestamp() computes
the true POSIX timestamp upper bound safely and deterministically across
all timezones.

Fixes arrow-py#1159
@Rajpal14
Rajpal14 force-pushed the fix/normalize-timestamp-large-values branch from d58c12f to acf2c99 Compare November 9, 2026 20:45

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

error in Time transform of 9999-12-31

2 participants