You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Skyfield >= 1.50 can cause "OverflowError: Python int too large to convert to C long" #1086
Running my Planet Visibility charts as usual looking for anything unusual, I bumped into a new error that is caused with Skyfield versions 1.50, 1.51, 1.52 and 1.53 (with a different line number in the last two cases).
First: my apologies for posting just screen dumps here. I only want to demonstrate what a good clean run looks like with Skyfield 1.49, and then show you the error listings with Skyfield 1.50 and 1.51, and then with Skyfield 1.52 and 1.53 in the hope that the last few lines of the traceback log might reveal something useful to you. For everyone else, the good news is that Skyfield 1.49 works perfectly for my use case.
The terminal log with Skyfield 1.49 - this is correct and how it should always be - I also turned off multiprocessing for all the following terminal log demonstrations:
The terminal log with Skyfield 1.50 or 1.51 throw the OverflowError: Python int too large to convert to C long error in timelib.py line 569 as follows:
The terminal log with Skyfield 1.52 or 1.53 throw the OverflowError: Python int too large to convert to C long error in timelib.py line 566 as follows:
I hope that this OverflowError alert from me is helpful to induce corrective investigation into the cause of this crash.
For information, I am using Python version 3.13.0
And I will happily re-test with future Skyfield versions.
I have whittled this issue down to a small program (which I don't really want to call an MWE) that illustrates two problems which occur with Skyfield versions 1.50 to 1.53 inclusive.
Running the program scans Saturn RISE and SET events per day in the year 1980.
Using Skyfield 1.49 there are no errors or warnings: it merely lists each day, i.e. "it works".
Using Skyfield 1.50 it complains about a divide by zero warning on June 15th 1980:
... and it crashes on December 27th with "OverflowError: Python int too large to convert to C long"
Here is my small test program (it only requires de421.bsp in the same folder:
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
from datetime import date, datetime, timedelta
from skyfield import VERSION
from skyfield.api import Loader, Topos, wgs84, N, S, E, W
from skyfield import almanac
def DOY(d00, daysinyear, idx):
# format day of year like 'Jan 1'
if idx is None: return "-NONE-"
if not 0 <= idx <= daysinyear:
return "idx={}".format(idx)
if idx == daysinyear:
return "Dec 31 24:00"
dt = d00 + timedelta(days=idx)
return "{dt:%b} {dt.day}".format(dt=dt)
print("\nSkyfield version = ",VERSION)
d = date(1980, 1, 1)
load = Loader("./")
ts = load.timescale()
eph = load('de421.bsp')
earth = eph['earth']
saturn = eph['saturn barycenter']
planet = saturn
lat = 0.0
latns = 'N' if lat >= 0.0 else 'S'
d00 = date(d.year, 1, 1)
daysinyear = (date(d.year+1, 1, 1) - date(d.year, 1, 1)).days
daystoprocess = daysinyear + 1
ts = load.timescale() # timescale object with built-in UT1-tables
print("planet: Saturn in 1980 at latitude {:.1f}°{}".format(abs(lat),latns))
#---------------------------------------------------------------------------
topos = wgs84.latlon(lat, 0.0 * E, elevation_m=0.0)
observer = earth + topos
dt = datetime(d.year, d.month, d.day, 0, 0, 0) # convert to datetime
t0 = None
idx = 0
while idx < daystoprocess:
print(DOY(d,daysinyear,idx))
if t0 is None:
# Note: do NOT use 'ts.ut1' as the date returned can be outside the requested boundary
# e.g. Saturn 2042 Feb 13 60°N returns RISE at 14 Feb 00:00:00
t0 = ts.utc(dt.year, dt.month, dt.day, dt.hour, dt.minute, dt.second)
t1 = ts.utc(dt.year, dt.month, dt.day+1, dt.hour, dt.minute, dt.second)
planetrise, iR = almanac.find_risings(observer, planet, t0, t1)
planetset, iS = almanac.find_settings(observer, planet, t0, t1)
# ------ assemble True events in chronological order ------
nR = len(planetrise); nS = len(planetset)
ndxR = ndxS = 0
riseset_time = []; isrise = []
while ndxR < nR or ndxS < nS:
if ndxR < nR and ndxS < nS: # if a RISE and a SET is available
if iR[ndxR] and iS[ndxS]: # if both are True events
if planetrise[ndxR] < planetset[ndxS]:
riseset_time.append(planetrise[ndxR]); isrise.append(True)
riseset_time.append(planetset[ndxS]); isrise.append(False)
else:
riseset_time.append(planetset[ndxS]); isrise.append(False)
riseset_time.append(planetrise[ndxR]); isrise.append(True)
elif iR[ndxR]: # if RISE is a True event
riseset_time.append(planetrise[ndxR]); isrise.append(True)
elif iS[ndxS]: # if SET is a True event
riseset_time.append(planetset[ndxS]); isrise.append(False)
ndxR += 1; ndxS += 1
elif ndxR < nR: # if only a RISE is available
if iR[ndxR]: # if RISE is a True event
riseset_time.append(planetrise[ndxR]); isrise.append(True)
ndxR += 1
elif ndxS < nS: # if only a SET is available
if iS[ndxS]: # if SET is a True event
riseset_time.append(planetset[ndxS]); isrise.append(False)
ndxS += 1
# ----------------------------------------- end of 'while'
if len(riseset_time) >=1:
dt0 = riseset_time[0].utc_datetime()
if len(riseset_time) >= 2: # this happens most often
dt1 = riseset_time[1].utc_datetime()
t0 = t1
idx += 1
dt += timedelta(days=1)
# ----------------------------------------- end of 'while'
I hope this is useful in reproducing and diagnosing the error.
Activity
aendie commentedon Jun 10, 2025
I have whittled this issue down to a small program (which I don't really want to call an MWE) that illustrates two problems which occur with Skyfield versions 1.50 to 1.53 inclusive.
Running the program scans Saturn RISE and SET events per day in the year 1980.
Using Skyfield 1.49 there are no errors or warnings: it merely lists each day, i.e. "it works".
Using Skyfield 1.50 it complains about a divide by zero warning on June 15th 1980:
... and it crashes on December 27th with "OverflowError: Python int too large to convert to C long"
Here is my small test program (it only requires
de421.bspin the same folder:I hope this is useful in reproducing and diagnosing the error.