Skip to content

BUG: fix read_sas large datetimes off by 2 days (GH#56014)#64344

Open
jbrockmendel wants to merge 4 commits intopandas-dev:mainfrom
jbrockmendel:fix-gh56014-sas-large-datetimes
Open

BUG: fix read_sas large datetimes off by 2 days (GH#56014)#64344
jbrockmendel wants to merge 4 commits intopandas-dev:mainfrom
jbrockmendel:fix-gh56014-sas-large-datetimes

Conversation

@jbrockmendel
Copy link
Member

@jbrockmendel jbrockmendel commented Feb 28, 2026 •
edited
Loading

After a few false starts, claude figured out:

SAS uses a modified Gregorian calendar where years divisible by 4000 are not leap years 
(unlike Python's proleptic Gregorian). Between 1960 and 9999 this affects years 4000 and 8000, 
producing a 2-day cumulative offset for max-range SAS dates. Real SAS 9.4 returns 
December 31, 9999; pandas was returning December 29, 9999.

This adds a correction function _sas_to_gregorian_correction so that we match the results SAS produces natively.

Claude wrote this, I reviewed it manually.
@jbrockmendel @claude
BUG: fix read_sas large datetimes off by 2 days (GH#56014)
0fb4f23 
SAS uses a modified Gregorian calendar where years divisible by 4000
are not leap years. Between 1960 and 9999 there are two such years
(4000 and 8000), causing a 2-day offset for max-range SAS dates.
Apply an additive correction in _convert_datetimes before casting to
datetime64, restoring agreement with real SAS 9.4 output.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@jbrockmendel jbrockmendel mentioned this pull request Feb 28, 2026
Closed
@jbrockmendel jbrockmendel force-pushed the fix-gh56014-sas-large-datetimes branch from 0bbd556 to 667daad Compare February 28, 2026 19:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

1 participant

@jbrockmendel