Leap second day utc2tai interpolation
See original GitHub issueHi astropy developers,
I am from North American pulsar time group(Nanograv). When I am processing some data taken in a leap second day(more exactly mjd 56109 ), I realize in that day, the leap second is interpolated. Here is a test I made.
>>> from astropy.time import Time
>>> test_leap = np.linspace(56107,56110,500)
>>> test_time = Time(test_leap, format='mjd', scale='utc')
>>> plt.plot(test_time.mjd, (test_time.tai.mjd - test_time.mjd)*86400.0)
And I have the plot.
My question what is the reason to do an interpolation, and is there any way to shut the interpolation off.
Thank you.
-Luo Jing
Issue Analytics
- State:
- Created 7 years ago
- Comments:11 (8 by maintainers)
Top Results From Across the Web
Leap-second considerations in distributed computer systems
the UTS clock is reduced by 0.1% from 23:43:21 to 24:00:00. → On a day with a negative UTC leap second, the last...
Read more >Leap second - Wikipedia
A leap second is a one-second adjustment that is occasionally applied to Coordinated Universal Time (UTC), to accommodate the difference between precise ...
Read more >NTP Leap Second and how they are handled by Meinberg ...
Insertion of a leap second is always scheduled for UTC midnight at the end of the last day of a month, preferably for...
Read more >It's time to leave the leap second in the past - Hacker News
The process most astronomy programs go through is to get the UTC from the user, convert the Gregorian date to a Julian day...
Read more >It's time to leave the leap second in the past
To visualize angular velocity change, think of a spinning figure skater. So far, only positive leap seconds have been added. In the early...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
In theory we can add a warning when anyone uses the
jd
ormjd
attributes of a UTC time object. I’m not generally a huge fan of warnings, but this does seems like a good case of “you are doing something that is likely to get you into trouble because there is a subtle implementation detail you might not be aware of.”This seems like a good compromise, especially since there is a correct way to calculate time differences in astropy given UTC input (difference the Time objects not the julian dates):