BUG: Ensure |jd2|<=0.5 - #9577

test failures are related

This looks good, though I'm a bit puzzled at the error - maybe it is just a matter of increasing atol in this case... I think we also need a test case that checks that the PR does what it intends to (can just be the example you found in #9533)

cc @taldcroft - this PR ensures abs(jd2)<=0.5 always - this was not something we ever guaranteed though we definitely have been trying to make it true, at least on input, on addition/subtraction, etc. Here, it adds a bit of time to every scale change; on balance, I think this is worth it, but would be good to have your input as well.

This looks good, though I'm a bit puzzled at the error - maybe it is just a matter of increasing atol in this case... I think we also need a test case that checks that the PR does what it intends to (can just be the example you found in #9533)

No, that's not it. You'll notice that the difference being raised is between -0.4999... and +0.5. The problem is that the code there (as in many other places) assumes that jd1 is an integer and jd2 the fractional part, and does the comparison on jd2 only. (jd1_a-jd1_b) + (jd2_a-jd2_b) would be fine - but I'm not sure that the rest of the test will still work, because it may well rely on assumptions about jd1 and jd2. I'll chase it down but it demonstrates the sort of way people build in assumptions about the possible values for jd1 and jd2 - so whether we actually made the guarantees or not, people - us! - have built them into code that uses astropy. So allowing scale conversion to subtly violate the conditions on jd2 is just asking for trouble. It is only efficiency concerns, and other assumptions about sharing of data, that keep me from wanting to make day_frac part of the jd1/jd2 validation applied to all time formats.

Should this have a changelog entry?

I don't think a changelog entry is needed - I'm happy to move this direction but perhaps best to keep it an "implementation detail" for now.

@taldcroft - are you OK with this?