-
-
Notifications
You must be signed in to change notification settings - Fork 217
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DeltaT and sunrise/sunset times #904
Comments
Could you include sample code, and show which time scale you are using? If you are using a timescale that includes ∆T, you should find a much better match between solar events and the time. |
Here is a simple example of the sunset.
['0023-03-21T06:33:07Z', '0023-03-21T18:41:05Z']
['2023-03-21T15:51:42Z', '2023-03-22T03:41:43Z'] |
Good! That output makes sense: because the UTC time scale ignores ∆T, it fails to follow the change in day length, both back into the past, and also forward into the future. Only over the narrow timespan of the past few decades, when leap seconds are active, does it follow sunrise and sunset and solar noon. So what you really want to do is compute sunrise and sunset, and then use those two times to define what ancient peoples would have called ‘the first hour’ and ‘the twelfth hour’. Failing that, you could get an approximate match using UT1, which does follow ∆T: https://rhodesmill.org/skyfield/time.html#ut1-and-downloading-iers-data But in my opinion it's best to ignore modern time scales and name ancient times using ancient sunrise and sunset, since that's what people at the time would have used. Note that even in modern times when UTC follows ∆T, sunrise on the equinox and sunset aren't at 6:00 and 18:00 because of the analemma: https://en.wikipedia.org/wiki/Analemma I'm going to close this issue as I don't think there's a bug with Skyfield involved here, but please comment further on this issue if you have any more questions! |
Thanks! |
You could get an approximate match using UT1, which does follow ∆T: https://rhodesmill.org/skyfield/time.html#ut1-and-downloading-iers-data |
There are two matters:
Thanks again |
Another serious problem I encountered because of delta-t is the calculation of the equation of time. Calculation of meridian transit:
convert time to LMT
convert day_transit to LMT
|
Each Python
Take the output of
My approach would be to compute afresh the timing of the “mean Sun” for the ancient year I am interested in. So, I would compute the times of all the solar transits for the year, then take an average across all of them, and call that the average solar noon for that year. Then, the equation of time would be computed compared to that. |
Hi.
transit_utc 0003-06-15 12:28:14.912553+00:00 |
Apparently the holidays and travel led to my losing track of your question — the tab I opened it in must have gotten closed accidentally! In case answers are still useful, more than a month later:
Yes! Leap seconds have been maintained from 1972 to the present: https://data.iana.org/time-zones/tzdb-2018a/leap-seconds.list For all previous eras, UTC is simply a count of SI seconds backwards into history that ignore UT1.
Then let's look for something quicker. I just added new rising, setting, and transit routines to Skyfield in the most recent release, that are much faster, so there's a good chance that we can speed up your calculation. But can we speed it up enough? We should start by asking: how much time can you afford for your software? How quickly does the computation need to finish? Also, could you outline what problem you are trying to solve which these calculations — what question you are trying to answer? Re-reading this thread, I'm not sure what your goal is. It might be that you could accomplish it with fewer calculations, and thus have a faster script. |
Thanks for your response.
So the topic title right now is, in my opinion, I am attaching the corrected code that I used, and sorry that the explanations are in Hebrew
|
In case any other contributors want to try out your script — I needed to remove the
And then there was another error, fixed with
The script then ran successfully! Running it over three years, I got this output — is this similar to what you're seeing?
By the way, you can switch to using Skyfield's new transit function, if you want your script to run a bit faster. Here is what the central part of your loop would look like:
So, to address your question:
With ∆T set to zero, we would expect solar noon to occur somewhere around noon Terrestrial Time. And since the difference between TT and UTC in 1999 was around 64 or 65 seconds (~32.1s for the difference between TT and TAI, and then 32 leap seconds between TAI and UTC), the value 65.0 prints out. Does that explain the result you are seeing from the script? |
Yes. Thanks! I think that explains it. The difference between TT and TAI is what caused the problem for me.
|
I'll look and see how you can most easily compute those offsets! But — would things be simpler if you just used TT, and stop using UTC? There's a method |
You wrote: "With ∆T set to zero, we would expect solar noon to occur somewhere around noon Terrestrial Time. And since the difference between TT and UTC in 1999 was around 64 or 65 seconds (~32.1s for the difference between TT and TAI, and then 32 leap seconds between TAI and UTC), the value 65.0 prints out." Try to do this calculation for the year 500. Is the data explained even then? day_transit by utc_datetime() comes out: ut1_calendar() and tt_calendar() give the same result: If you take utc_datetime() and add 47 seconds to it you will get: |
The very first leap second was in 1972, and moved the TAI - UTC offset from 10 to 11 seconds. Here's how you can print the leap second table:
The result:
Does that explain the offset you're seeing? |
Well, even if we use tt_calendar() the average transit at longitude 0 does not come out at 12:00 if we go to a year like year 500 (difference of about 5 seconds) or year 2 (difference of 8 seconds) then your first explanation might have been correct For 1999 but for very early years I still have a second gap that I don't know how to explain. And as I said: the right time scale for me is a time scale where the average transit will be at 12:00. For this purpose, I changed the following lines from the code I provided above as follows:
|
Let me know when you have the chance to try out the new |
wow It's really wonderful. I did a test on 50 years using the old method including exporting a csv file, and it took 3 minutes and 10 seconds (from the moment I confirmed the restart kernel). Here is the code I used. I put the old code inside ''' ''' so it won't be active.
|
Here is the new code in clean form, with an English translation.
|
I spent a couple of hours this weekend looking at your sun-averaging idea, and I would indeed have thought that averaging the Sun's position would have resulted in a match for the ∆T value. But, like you, I see a several-second offset between them. One adjustment I made was to not use transits, because they are not even samples — they are clustered closer together at aphelion, and are farther apart at perihelion, so they don't evenly sample the Sun's position. But that only helped a little. If someday I have time for a deep dive into all the math, I'll let you know what I find; but until then, the few-second different at year 500 (and the growing difference before that) will, alas, remain a mystery! For your application, I would leave ∆T at its default value, and for each day, record its anti transit, sunrise, solar noon, and sunset, because those are the four things that the ancient observer would be able to measure; they wouldn't, for example, be able to track the difference between apparent time and our modern concept of mean time. Then use those four reference points to define the hours of the day and watches of the night. |
I am very grateful for all the helpful discussion. The new transit function was very helpful. For myself, I think the method I suggested is the best method for me right now, and I use it in my software to fix the delta-t zero time scale. |
updating: |
Skyfield includes DeltaT in the time calculation.
but there is a problem.
DeltaT is very important when trying to calculate ancient astronomical events such as Halley's Comet, etc., which are trying to calculate them backwards according to the known rate at which they occur. And also regarding solar eclipses and the like.
But when trying to calculate daily times, such as sunrise, sunset, and meridian transit, it creates a problem, and I will give an example.
Let's take Jerusalem as an example.
Every year on the date of Vernal Equinox the sun sets around 18:00 according to standard local time which is: UTC+2.
But when I try to do the same calculation for 23 AD, that is 2000 years back, the sun sets at about 21:00 at the Vernal Equinox in Jerusalem, according to UTC+2.
The reason why the sun supposedly sets at 21:00 is because deltaT comes into the calculation. And in 23 AD deltaT was about 10,417 seconds which is 173 minutes which is close to three hours.
But no person in Jerusalem thought in 23 that the sun sets at 9:00 p.m. It is clear that they thought that the sun sets at 18:00 and of course the middle of the day was at 12:00 and not at 15:00
The text was updated successfully, but these errors were encountered: