I think you are correct. It then begs the question is the julian strings in Time should not just have TT as the default time scale (@taldcroft?)....

I don't actually know how to determine the "true" J2000 definition.

I've had this struggle in poliastro as well. USNO Circular 179 uses TT, but the JPL ephemerides (HORIZONS, SPICE) use TDB:

poliastro/poliastro@35431a6

In any case, either of those is better than UTC. I use J2000 as reference epoch a lot, and when you add large timedeltas to it you start getting warnings about future leap seconds, which doesn't happen in the other timescales.

Right now this creates an inconsistency between...

I agree with @mhvk here, that J* strings should use TT by default.

Alright, I've updated this to do as you both suggested, @mhvk and @Juanlu001 and now J-strings (and J epochs that are floats) in Time also go to 'tt'.

This still leaves the question of whether we want a deprecation period. I'm willing to make a command decision there if the three of us agree in coordinates, but since this now also affects time, I'm less certain. Are you willing to make this call, @mhvk, or do you think it has to wait on @taldcroft (who I think can't look until after tonight's feature freeze).

An alternative is to save the Time changes for 4.0 and instead just change TimeAttribute in this PR... That feels like stretching out a confusion, but it is a possible middle ground...

@eteq - I think we're duplicating each other... See #8600

As I suggested in #8600 (comment) I've rolled this back to not include Time modifications, as @mhvk's #8600 fit is a better direction. The idea would be to merge this to make sure we get the coordinates parts in, but #8600 would do the Time changes (which might involve partly backing out the final commit in this PR).

Since we ruled this a bug in #8600 it's backportable (although it definitely should come before #8600 for the backport to be sensible)

The errors seem unrelated: <SAMPProxyError 1: 'Timeout expired!'> and docstring of astropy.cosmology.FLRW.Odm:27:Unexpected section title or transition.

Looks like @eteq and @mhvk have competing PRs? I'll let them figure it out first...

@pllim - you mean #8600, right? In #8600 (comment) (and #8594 (comment)) I proposed we merge this as the coordinates changes (as I think in #8600 (comment) @mhvk agreed that at least part of this approach was better for coordinates), and then #8600 can be rebased on top of this to focus more on the time changes (for which @mhvk's solution was definitely superior) and perhaps some of the tests (to make them all more consistent).

And re: the test failures, I agree wit @Juanlu001 they are probably red herrings - it looks like the doc failure was unrelated (fixed in #8626) an the other one is a timeout so re-started the build just to be sure

Thanks for the clarification, @eteq . In that case, I propose that @mhvk should press the approve button.

(note: the one CI error is a red herring as it's a doc problem in cosmology and unrelated)

Codecov Report

Merging #8594 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #8594      +/-   ##
==========================================
+ Coverage   86.93%   86.94%   +<.01%     
==========================================
  Files         399      400       +1     
  Lines       59249    59329      +80     
  Branches     1100     1100              
==========================================
+ Hits        51511    51586      +75     
- Misses       7097     7102       +5     
  Partials      641      641

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2d84c4f...50def24. Read the comment docs.

Updated as suggested by @taldcroft . Re:

I note that there will be a number of conflicts with #8600 since that goes the route of removing the explicit scale='utc' instead of replacing it with scale='tt'. I would have done it like in #8600 (remove and rely on default), but either way is OK.

My thinking is that it's better to be explicit here because that way people looking at it in coordinates will see the answer mainfestly instead of having to figure out the implicit meaning. But I think we should also fix it in time a la #8600 so I'm thinking to merge this and then rebase that over this.

(merged based on #8600 (comment) and approval)