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
Leap seconds before 1973 ignored by IERS_Auto(), no errors for below range. #13494
The IERS_Auto() table uses IERS_A, replacing values with IERS_B where the latter is valid. This is good. But a problem is that IERS_A does not go back as far as IERS_B, and hence before 1973 all leap seconds are ignored. There are two questions here:
Is it worth merging in the pre-1973 IERS_B data automatically (I think this is an obvious yes);
Should IERS_Auto() error for times before its valid range? Currently, it doesn't error for times after, for which there are no predictions, and this is fine. But perhaps for times before the valid range, it should still stick to the user-given way to deal with out-of-range errors?
Yes, makes sense to merge in the pre-1973 IERS-B data.
How would that error be actionable? If I understand there are really no predictions so apart from learning about this fundamental limitation in timekeeping, is there anything they can do about it? Personally I think the handling should be the same on both ends.
As for actionable, I think the difference in the two ends is that one can easily see reasons for wanting UT1 beyond the valid range (telescope scheduling), but a time before the valid range is much more likely a bug, where perhaps it makes sense for the user to explicitly silence it. But note that I don't have a strong opinion; with Time, it remains the case that generally we expect the user to be aware of what they are doing.
Activity
taldcroft commentedon Jul 26, 2022
@mhvk -
mhvk commentedon Jul 26, 2022
OK, let's do the merge at least.
As for actionable, I think the difference in the two ends is that one can easily see reasons for wanting
UT1beyond the valid range (telescope scheduling), but a time before the valid range is much more likely a bug, where perhaps it makes sense for the user to explicitly silence it. But note that I don't have a strong opinion; withTime, it remains the case that generally we expect the user to be aware of what they are doing.