Times outside of the IERS table shouldn't raise exception. #3105

Activity

1. bnordgren commented on Nov 14, 2014

   

   bnordgren

   on Nov 14, 2014

   ContributorAuthor

   More actions

   Investigating further, math with time objects does not carry the delta_ut1_utc attribute into the result. My unit test below fails at the assert statement:

       def test_early_sidereal_time(self) : 
           test_time = t.Time('1901:001', format='yday')
           test_time.delta_ut1_utc = 0
           test_time.sidereal_time('apparent','greenwich')
           test_time2 = test_time + (1*u.day)
           self.assertTrue(hasattr(test_time2, "delta_ut1_utc"))
           test_time2.sidereal_time('apparent','greenwich')
2. embray

   added

   time

   on Nov 17, 2014
3. mhvk commented on Nov 19, 2014

   

   mhvk

   on Nov 19, 2014

   Contributor

   More actions

   @bnordgren - on the failure in your example: this is a feature, not a bug 😸 -- when you go to another time, the precalculated UT1-UTC is no longer valid, so it is not copied over (e.g., suppose you add the day just around the time of a leap second, or add 100 years). Of course, in "normal" usage, it will just get recalculated when you try to get the sidereal time).

   As for the more general problem, as I understand it, UTC itself is not defined at early and late times. My feeling is that Time should not start to make approximations -- part of its current beauty is that it will do the right thing, and in most code, if one is outside of the valid range, very likely something has gone wrong, so an error is appropriate -- but rather provide the possibility to set the offset by hand. So, you could wrap the relevant pieces of code inside a try/except clause, where you set t.delta_ut1_utc = <whatever> if needed. Or, if precision is not too important, just use UTC throughout.

   cc @taldcroft.
4. taldcroft commented on Nov 30, 2014

   

   taldcroft

   on Nov 30, 2014

   Member

   More actions

   @bnordgren - following on @mhvk's comment, depending on your precision requirements maybe you can just set test_time2.delta_ut1_utc = 0 as well?

   Alternately if you could try coding up the algorithm you mentioned, it could be included as a time utility function for cases like yours. Perhaps with sufficient validation and documentation it might be possible to automatically use such an approximation outside the range of the IERS tables, but that would be a separate discussion. We would definitely appreciate a contribution on your part!!
5. bnordgren commented on Dec 2, 2014

   

   bnordgren

   on Dec 2, 2014

   ContributorAuthor

   More actions

   @taldcroft Yup, can definitely set it to zero: https://github.com/firelab/met_utils/blob/master/orchidee_indices.py#L324

   My use case is to calculate daylength, so I don't actually lose precision by setting delta_ut1_utc to the wrong value (e.g., it doesn't change much in a day, and I'm subtracting sunrise from sunset.) The algorithm calls for "sidereal time", tho, so I can't just use UTC. The ugly bit is that after every arithmetic operation I have to manually check to see whether I need to set the attribute on the result.

   @mhvk My understanding is that under "normal" circumstances, the delta_ut1_utc attribute doesn't exist on a Time object. So if it's there, it was manually put there by someone who wanted to override the normal behavior. :) Stripping out something the human put there is back to being a bug. :) Jus' sayin'.
6. mhvk commented on Dec 3, 2014

   

   mhvk

   on Dec 3, 2014

   Contributor

   More actions

   @bnordgren - I still don't think it is a bug ;-) The value might just as well have been set outside astropy to a better approximation that we provide, and then one would not want to propagate it in arithmatic.... Time very much tries to ever avoid giving the wrong answer.
7. taldcroft commented on Nov 2, 2015

   

   taldcroft

   on Nov 2, 2015

   Member

   More actions

   Discussion converged on the feeling that this is required for Time (feature not bug). Closing.
8. taldcroft

   closed this as completedon Nov 2, 2015