Skip to content

Change default timescale for epochs to 'tt' - #8600

Merged
bsipocz merged 8 commits into
astropy:masterfrom
mhvk:time-julian-tt
May 5, 2019
Merged

bsipocz merged 8 commits into
astropy:masterfrom
mhvk:time-julian-tt

Conversation

@mhvk

@mhvk mhvk commented Apr 19, 2019 •

Copy link
Copy Markdown
Contributor

See discussion in #8594.

Still to do: adjust coordinate tests to not set time scale for equinoxes to 'utc'

@astrojuanlu astrojuanlu left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@pllim pllim added the wcs label Apr 19, 2019
@pllim

pllim commented Apr 19, 2019

Copy link
Copy Markdown
Member

Today is feature freeze day, so the sooner you can fix the tests, the better. 😅

@pllim

pllim commented Apr 19, 2019

Copy link
Copy Markdown
Member

So, is this supposed to fully address #8594 or just parts of it?

@mhvk

mhvk commented Apr 19, 2019

Copy link
Copy Markdown
Contributor Author

@eteq - the change in Time to a default of "tt" for epochs was relatively easy, but many tests had to be adjusted, including one that points to a possible problem (in wcs; see in-line comment). Could you have a look? I think I have more or less inadvertently also included your changes in #8594.

assert tuple(mywcs.wcs.ctype) == ('TLON-CAR', 'TLAT-CAR')
assert mywcs.wcs.radesys == 'ITRS'
assert mywcs.wcs.dateobs == Time('J2000').utc.isot
assert mywcs.wcs.dateobs == Time('J2000').utc.fits

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at this again, I realize the change is actually not necessary, but it is probably good to mention that dateobs will now be '2000-01-01T11:58:55.816' - it would probably be better if the time system was also stored (as it is in FITS).

from astropy.utils.exceptions import AstropyWarning


# The UTC time scale is not properly defined prior to 1960, so Time('B1950',

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed the comment since it is now basically consistent, though note that I just went for tt for B1950 too.

@codecov

codecov Bot commented Apr 19, 2019

Copy link
Copy Markdown

Codecov Report

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

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #8600      +/-   ##
==========================================
+ Coverage    86.9%   86.91%   +<.01%     
==========================================
  Files         393      393              
  Lines       58584    58587       +3     
  Branches     1064     1064              
==========================================
+ Hits        50914    50919       +5     
+ Misses       7051     7049       -2     
  Partials      619      619
Impacted Files Coverage Δ
astropy/coordinates/builtin_frames/utils.py 94.11% <100%> (ø) ⬆️
astropy/coordinates/earth_orientation.py 71.42% <100%> (ø) ⬆️
astropy/time/formats.py 97.52% <100%> (+0.01%) ⬆️
astropy/utils/data.py 81.37% <0%> (+0.44%) ⬆️

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 d1f2fd5...13c236e. Read the comment docs.

@codecov

codecov Bot commented Apr 19, 2019 •

Copy link
Copy Markdown

Codecov Report

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

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #8600      +/-   ##
==========================================
+ Coverage   86.95%   86.95%   +<.01%     
==========================================
  Files         399      399              
  Lines       59329    59332       +3     
  Branches     1100     1100              
==========================================
+ Hits        51587    51590       +3     
  Misses       7101     7101              
  Partials      641      641
Impacted Files Coverage Δ
astropy/coordinates/builtin_frames/utils.py 94.11% <ø> (ø) ⬆️
astropy/coordinates/earth_orientation.py 71.42% <100%> (ø) ⬆️
astropy/time/formats.py 97.52% <100%> (+0.01%) ⬆️

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 4166b6a...8734792. Read the comment docs.

@eteq

eteq commented Apr 19, 2019

Copy link
Copy Markdown
Member

Oops! How do we resolve the collision in #8594, @mhvk? I actually prefer the explicit setting over using the string machinery in coordinates... so perhaps we can literally merge these two branches and then merge into master?

@eteq

eteq commented Apr 19, 2019 •

Copy link
Copy Markdown
Member

(I do prefer your implementation on the time side here, though, over mine)

@mhvk

mhvk commented Apr 20, 2019

Copy link
Copy Markdown
Contributor Author

Agreed that at least in the actual code, it is clearer to explicitly set the time-scale. I do think that for the tests it is better not to set the scale explicitly to something we now feel is wrong, and I took the lazy way out...

More on topic: I would certainly prefer to have @taldcroft sign off on this, though in principle I guess it could be to revert if he feels this is a bad idea.

Practically, I've run out of time here... Since this is technically a bug (though one with repercussions), perhaps we can postpone it?

@eteq

eteq commented Apr 20, 2019 •

Copy link
Copy Markdown
Member

@mhvk - Yep point taken that we can consider it a bug. Maybe I should roll back #8594 to before the Time change (I e. just the coordinates part) and merge that now, but we try to get this in as a bug fix in time for 3.2 release?

@taldcroft taldcroft left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

.. back from vacation.

This looks good to me. I'm generally in favor of making the changes in time and coordinates in one go for this release. I just wonder about getting appropriate visibility. Maybe a What's New mention?

It's kind of a bigger topic, but I do find it useful (as done in e.g. numpy) to have the version when things changed or were added in the narrative / API docs. E.g. in relevant places we would see a comment like "Default time scale for epoch times like J2000 changed from UTC to TT in version 3.2". The point being that the change log is not where most people wind up when learning about a function or method.

@mhvk

mhvk commented May 1, 2019

Copy link
Copy Markdown
Contributor Author

👍 to (an equivalent of) .. versionchanged:!

@eteq

eteq commented May 1, 2019

Copy link
Copy Markdown
Member

To clarify one thing since there's some cross-conversation... I did this part a few days ago:

Yep point taken that we can consider it a bug. Maybe I should roll back #8594 to before the Time change (I e. just the coordinates part) and merge that now, but we try to get this in as a bug fix in time for 3.2 release?

in #8594. I think that's good to merge if @mhvk gives it a 👍 (and then this can be rebased on that)

@mhvk

mhvk commented May 1, 2019

Copy link
Copy Markdown
Contributor Author

Please don't wait for me - I'm off traveling. So, maybe someone else can do the review? With everybody agreeing that we should propagate this to Time, I'm fine with the overall scheme and I do hope to get to rebasing this PR once the other is in.

@mhvk
mhvk force-pushed the time-julian-tt branch 2 times, most recently from c69b907 to ae0e35a Compare May 1, 2019 23:18
@mhvk

mhvk commented May 1, 2019

Copy link
Copy Markdown
Contributor Author

I rebased this just in case we want to merge just this PR. I'm about to board, but think I'll have some time later in the week to rebase if the other PR is merged first.

@mhvk

mhvk commented May 1, 2019

Copy link
Copy Markdown
Contributor Author

ps. Do feel free to just edit & merge without my comments; I think we all agree what needs to be done here!

@eteq

eteq commented May 3, 2019

Copy link
Copy Markdown
Member

I'll try to rebase this over the merged #8594 if I can, but if I haven't gotten to it by the time you get some time, @mhvk, feel free!

@eteq
eteq force-pushed the time-julian-tt branch from ae0e35a to 8734792 Compare May 4, 2019 21:51
@eteq

eteq commented May 4, 2019

Copy link
Copy Markdown
Member

Alright, I've rebased this and the tests are all passing for me locally. I also added a what's new entry (which applies for this and #8594 ). Assuming the tests pass I think this is all set. Note, though, that this must be backported after #8594

@eteq eteq added the zzz 💤 merge-when-ci-passes Do not use: We have auto-merge option now. label May 4, 2019
@bsipocz
bsipocz merged commit 5aa9142 into astropy:master May 5, 2019
@bsipocz

bsipocz commented May 5, 2019

Copy link
Copy Markdown
Member

Note, though, that this must be backported after #8594

#8594 has been already backported, so it's all good :)

bsipocz added a commit that referenced this pull request May 6, 2019
Change default timescale for epochs to 'tt'
@mhvk
mhvk deleted the time-julian-tt branch June 4, 2019 17:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants