I wan’t to transform timescales from JD to TT using astropy.time.
But when the JD- Number gets very small, which means back in time for thousand of years, I recive wrong results, compared with the Nasa JD-TT-transform-tool. So here is my very simple codesnippet:
from astropy.time import Time
times = [1739331.875]
t = Time(times, format=‘jd’, scale=‘tt’)
t.iso
The result is: array([‘50-01-10 09:00:00.000’], dtype=‘<U21’)
but its 2 days to early and should be: ‘50-01-12 09)’
So could you please tell me whats wrong on the code?
The astropy states that timeconversions are able from the bigbang onto the far future,
but when I go back in time with this code, the error inreases more and more.
The issue here is the 1582 adoption of the Gregorian calendar over the Julian calendar (Gregorian calendar - Wikipedia). There is a ten-day jump at that transition, and prior to that, the handling of leap days is different between the two calendars.
Astropy uses the Gregorian calendar exclusively. However, this means that care needs to be taken when comparing against historical dates that use the Julian calendar.
The tool from the JPL SSD group uses the Gregorian calendar after JD 2299160.5 and the Julian calendar prior to JD 2299160.5. From their tool:
Note the ten-day jump for a miniscule change in JD. This choice by their tool also has the undesirable property where the calendar->JD conversion is degenerate, e.g.:
Thank you ayshih for this precise explanation.
I’m workink with the ephemeries- generating- software SOLEX from the italian Professore Aldo Vitagliano and find therein the same issue like the NASA- transformer have. So is this coupling of julia. & greg. calendar a common usage? And what is the status of the astropy procedure here?
By the way I asked the OpenAI ChatGPT and got the answer, that astropy have the package
“TimeScaleInfo” with wich one can do transformations like the NASA- tool.
The whole recommended Python-code of ChatGPT is:
from astropy.time import Time
from astropy.time import TimeScaleInfo
# Define the JD time (in this example, JD = 1739331.875)
jd_time = Time(1739331.875, format='jd')
# Get the TT time using the built-in Astropy conversion
tt_time_astropy = jd_time.tt
# Get the difference between JD and TT at the given time using IERS data
tai_minus_tt = TimeScaleInfo().get_delta_t(jd_time, 'tai') - TimeScaleInfo().get_delta_t(jd_time, 'tt')
# Calculate the correct TT time using the difference
tt_time_correct = jd_time.tt + tai_minus_tt
# Print the TT time in ISO format
print(tt_time_correct.iso)
The problem is, that I can’t load the
TimeScaleInfo- package and I think its an old one which is out of reach.
So is there a way to calculate the NASAs transformation from JD to TT and backwards?
Best regards, Norbert
I would caution that it is tricky to define a single transition date between the Julian calendar and the Gregorian calendar because the countries that transitioned in 1582 were primarily only Catholic countries, with other countries transitioning years/decades/centuries later. As an extreme example, Saudi Arabia did not adopt the Gregorgian calendar until 2016.
If you really need to handle Julian-calendar dates, you could use a different package, such as skyfield. Just as with Astropy, the default behavior of skyfield is to use the Gregorian calendar for all historical times. However, skyfield has the additional option of defining a transition between the Julian calendar and the Gregorian calendar: Dates and Time — Skyfield documentation
You are welcome to submit a feature request to the Astropy folks.
Thank you Albert,
now I can see the thinks better. Of course it would be very easy to use the gregorian calendar as strandard for the whole past and future. And if the NASA would have to introduce the best and modernest timescale, they should prefer the ‘only-gregorian-style’.
The practical aspect for using also the julian calendar could be, that many old data are listed in that one, so with respect to the common historian usage, the julian calendar has its right.
But with the view of an most easy and unified system for the future, the ‘only-greg-style’ should be the best. So why does NASA not prefer it? As the julian calendar was actual, the astronomian knowledge was very undeveloped… So the modern astronomy should use the most easy and unified scales as standard, and than add all the apps for translating into the older measures.
So why? Or is there something I dont even know?
Is astropy ahead of our time?
Best wishes from Germany, Norbert
As you acknowledge, the appropriate choice between using the Julian calendar prior to 1582 or using the (so-called) proleptic Gregorian calendar depends on the use case. (Incidentally, the table in the linked Wikipedia article shows the difference of 2 days in 50 AD.) Neither choice is wrong. Despite the advantages of using the proleptic Gregorian calendar, if you have to work with historical data, switching to the Julian calendar is unavoidable.
The online tool provided by the JPL SSD group is not used by all of NASA. The tool is designed correctly for historical use cases that use the Julian calendar, and it matches other references and programs that target those same use cases. But, the availability of this one tool does not mean that other parts of NASA prefer the Julian calendar over the proleptic Gregorian calendar. In fact, I believe that Astropy is partially funded by NASA.
What the JPL SSD tool is lacking is documentation that it uses the Julian calendar prior to 1582, and it’d be even better if it offered a way to select the proleptic Gregorian calendar instead.
You may are a wise connoisseur of Astropy, so let me now ask you a somewhat blasphemous question: Suppose I want to create a post-galactic chart and want to set up an extended time scale say from -10000 BC to 10000 AD. In this range I want to transform TT- times into JD back and forth. This is even not easy possible with astropy.time!
…The ChatGPT is already glowing from my many questions. But I found out so far, that negative year inputs are not easy to handle with astropy.
In the astropy- documentation you can find this great statement at the beginning:
“All time manipulations and arithmetic operations are done internally using two 64-bit floats to represent time. Floating point algorithms from [1] are used so that the [Time] object maintains sub-nanosecond precision over times spanning the age of the universe.”
… spanning the age of the universe… But in reality calculatuions even to TT -10000 are nearly impossible…(?) Offers the skyfield such an possibility? To me it seems, that the astropy.time - module handles timescales not even longer than the datetime - module of Python.
Can you give me a little tip, how I can process transformations from TT to JD and back for some millenias BCE?