-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add_t_step not correct for long timespans #803
Comments
This problem starts after stepping forward ca 68 years, starting from either f.ex year 2000 or year 2100. |
EclSum's |
Leap seconds was my hypothesis too, but I have failed to understand where they enter the calculation and thus how it causes this. |
Okay nevermind. It's due to floating-point conversions. import ctypes
import datetime
x = datetime.datetime(2500, 1, 1)
y = datetime.datetime(2000, 1, 1)
# from EclSum.add_t_step
sec = (x - y).days * 24 * 60 * 60 # => 15778540800
sec_f32 = ctypes.c_float(sec).value # => 15778540544.0
minute_diff = (sec - sec_f32) / 60 # => ~ 4.267
computed_date = y + datetime.timedelta(seconds=sec_f32) # => datetime.date(2499, 12, 31) This might still not be fixable in short order due to our requirement for C ABI compatibility, and changing the type from |
Thanks, makes sense. No apparent workaround. If this only affects synthetic UNSMRY it is not of high priority. |
Stepping 500 year forward in time, the EclSumTStep is off by ~5 minutes:
The text was updated successfully, but these errors were encountered: