timescale With delta-T 0.0 Gives errors for the moon

[sgbmzm]

Hello.
For the Sun, I've been fine with setting delta-T to 0 on the time scale, but for the Moon, and probably other planets too, there are errors.

Note! The problems were discovered for the year 0094 where there is a large delta-t gap. It is possible that near the present the problem will not exist, but I deliberately brought the examples about the year 0094

Examples:

from skyfield.api import N, S, E, W, wgs84, load, load_file
from skyfield import almanac


eph = load('de441.bsp')
jerusalem = wgs84.latlon(31.776812 * N, 35.235694 * E)
observer = eph['Earth'] + jerusalem

ts = load.timescale()

t0 = ts.utc(94, 2, 2)
t1 = ts.utc(94, 2, 3)

print()
print("delta_t Default")

t, y = almanac.find_settings(observer, eph['SUN'], t0, t1, horizon_degrees=0.0)
print('Sunset (UT1):', t.ut1_strftime())
print('Sunset (UTC):', t.utc_strftime())

t, y = almanac.find_settings(observer, eph['Moon'], t0, t1, horizon_degrees=0.0)
print('Moonset (UT1):', t.ut1_strftime())
print('Moonset (UTC):', t.utc_strftime())


print()
print("delta_t=0.0")

ts = load.timescale(delta_t=0.0)

t0 = ts.utc(94, 2, 2)
t1 = ts.utc(94, 2, 3)

t, y = almanac.find_settings(observer, eph['SUN'], t0, t1, horizon_degrees=0.0)
print('Sunset (UT1):', t.ut1_strftime())
print('Sunset (UTC):', t.utc_strftime())

t, y = almanac.find_settings(observer, eph['Moon'], t0, t1, horizon_degrees=0.0)
print('Moonset (UT1):', t.ut1_strftime())
print('Moonset (UTC):', t.utc_strftime())

OUTPUT:

delta_t Default
Sunset (UT1): ['0094-02-02 15:14:07 UT1']
Sunset (UTC): ['0094-02-02 17:51:09 UTC']
Moonset (UT1): ['0094-02-02 15:59:27 UT1']
Moonset (UTC): ['0094-02-02 18:36:29 UTC']

delta_t=0.0
Sunset (UT1): ['0094-02-02 15:13:35 UT1']
Sunset (UTC): ['0094-02-02 15:12:53 UTC']
Moonset (UT1): ['0094-02-02 15:51:16 UT1']
Moonset (UTC): ['0094-02-02 15:50:34 UTC']

Note that when it comes to the sun, there is a difference of about half a minute between: UT1 with normal delta-T and UT1 with delta-T 0.0
On the other hand, for the moon there is a difference of 8 minutes! Between: UT1 with normal delta-T and UT1 with delta-T 0.0

In both cases UTC moves back and almost reaches UT1 when delta-t is set to 0.0. And so it should be

another example:

from skyfield.api import N, S, E, W, wgs84, load, load_file
from skyfield import almanac

eph = load('de441.bsp')


ts = load.timescale()


print()
print("delta_t Default")

t0 = ts.utc(94, 1, 20)
t1 = ts.utc(94, 2, 8)

f = almanac.oppositions_conjunctions(eph, eph['moon'])
t, y = almanac.find_discrete(t0, t1, f)

print(t.ut1_strftime())
print(t.utc_strftime())
print(y)


print()
print("delta_t=0.0")

ts = load.timescale(delta_t=0.0)

t0 = ts.utc(94, 1, 20)
t1 = ts.utc(94, 2, 8)

f = almanac.oppositions_conjunctions(eph, eph['moon'])
t, y = almanac.find_discrete(t0, t1, f)

print(t.ut1_strftime())
print(t.utc_strftime())
print(y)

OUTPUT:

delta_t Default
['0094-02-01 23:45:50 UT1']
['0094-02-02 02:22:52 UTC']
[1]

delta_t=0.0
['0094-02-02 02:23:34 UT1']
['0094-02-02 02:22:52 UTC']
[1]

In this case, the time of the conjunction of the moon with the sun according to UT1 is correct when delta-T is by default, but when delta-T is set to 0.0 there is a problem: UT1 has moved forward towards UTC which is not a good thing. The opposite should have happened: UTC should go back towards UT1.

These problems cause serious malfunctions in my software, and I would be very happy if the cause of these problems, and the solution, were revealed.
Thank you

[sgbmzm]

Is there an idea for a solution to the problems I presented? I am very grateful

[brandon-rhodes]

The opposite should have happened: UTC should go back towards UT1.

Let's tackle this idea first, since I think it's the most important. Prior to the first leap second, UTC is a completely uniform atomic timescale. Whatever we might do with ∆T, we would not expect the UTC time of something like a conjunction to change at all. It couldn't, I don't think? The conjunction happens whenever Solar System orbits say it's going to happen, right? And that moment will have an exact UTC timestamp that doesn't change.

What we would, indeed, expect to change would be the UT1 timestamp for the event, because UT1 is a wobbly irregular timescale whose days can be long or short or somewhere in between. ∆T is precisely the measure of how wobbly UT1 has gotten by a particular point in history, and how much error has accumulated in it compared to an absolute atomic timescale. So setting ∆T should change UT1, not UTC.

So a first problem might be that maybe you have the two timescales reversed in your head by accident? Let me know if the Skyfield docs say the wrong thing about them somewhere, and I'll get that fixed!

[sgbmzm]

Thanks so much for your response!

Of course you are right that UT1 is the one that changes, but I am talking about what actually happens in the skyfield in the examples I gave.
Skyfield behaves differently between the sun and the moon regarding the use of the different time scales, and as I have given in the examples, and I do not know the reason for this.

My impression is, at least for the sun, that by default, when skyfield uses a UTC timescale, it inserts the delta_t calculation into it so that timescale includes the delta_t effect, whereas when I ask for output in the UT1 timescale, what skyfield does is reduce the value of delta_t is the time scale to reach UT1.
On the other hand, when I set delta_t = 0.0 to skyfield, it receives real UTC input without delta-t, so there won't be a big difference if I ask for UTC output or UT1 output, and the time I get in both is close to the time I got in UT1 when I used delta -T is normal without setting 0.0. But for the moon the opposite happens in Skyfield, and the time I will get in both is close to the time I got in UTC when I used normal delta-t without setting 0.0.

When delta_t is zero, there shouldn't be much difference between UTC and UT1.

Regarding the first example, indeed for Sunset when delta_t is zero the difference is less than a minute. So why about the moon there is a difference of 8 minutes.

[brandon-rhodes]

So if we agree about how UTC and UT1 behave, then let's go backwards through the issues brought up in the original issue, as your final question is the simplest:

In this case, the time of the conjunction of the moon with the sun according to UT1 is correct when delta-T is by default, but when delta-T is set to 0.0 there is a problem: UT1 has moved forward towards UTC which is not a good thing. The opposite should have happened: UTC should go back towards UT1.

As we agreed in our previous two comments, this is exactly what we should expect. UTC is a constant atomic timescale (pre-leap-seconds), so adjusting ∆T has no effect on it at all. The UTC times of the conjunctions remain the same, exactly as we would expect for a uniform time scale — both times, the conjunction is at 0094-02-02 02:22:52 UTC.

The only thing that ∆T changes is UT1. When ∆T=0, they have an offset of 42 seconds. When instead ∆T has its true historic value, they are more than two hours apart by the first century.

So we can turn to your first question:

On the other hand, for the moon there is a difference of 8 minutes! Between: UT1 with normal delta-T and UT1 with delta-T 0.0

Let’s tackle your second output first:

delta_t=0.0
...
Moonset (UT1): ['0094-02-02 15:51:16 UT1']
Moonset (UTC): ['0094-02-02 15:50:34 UTC']

I think you’ll agree that this is entirely as expected. With ∆T=0, the difference in timescales is around 42 seconds, and so the exact same Moon setting event is given two times that differ by 42 seconds.

Now let’s look at your first output:

delta_t Default
...
Moonset (UT1): ['0094-02-02 15:59:27 UT1']
Moonset (UTC): ['0094-02-02 18:36:29 UTC']

Here we might have found the source of your confusion. ∆T affects these numbers not in one way only, but in two different ways:

1. As before, ∆T changes the name of each time by more than two hours.
2. But ∆T also changes the moment of setting itself because UT1 is not merely a way of naming times on history’s timeline, but it is also the physical direction in which the Earth is pointing at any given moment. It's an angular measure of the Earth's actual rotation, so changing ∆T tells Skyfield to take the Earth and twist it to point in a different direction.
3. And, the Moon will have moved a few degrees in that two-plus hours that it waits to set, making yet another difference to the result.

So by letting ∆T have a true historic value, you are changing the angle of the Earth itself, the planet itself, by more than 2 hours out of 24, and thus by more than 30°. So anything like a rising or setting is going to happen at a drastically different time.

And so your result will be different for three separate reasons: first, because the actual moment of rising or setting is several hours different; and, second, because you’re using a UT1 that includes true ∆T and not a ∆T=0; and, third, because the Moon moves over that time.

I think you’ll find that these differences, together, account for the difference in time in this second example.

[sgbmzm]

Thank you!
Probably what you wrote can explain, but in any case the thing I wanted to do as I suggested in #904 to direct the time scale was not successful towards the moon but only towards the sun, maybe really because of the movement of the moon itself, and because I looked at delta-T as a way to count times only .
I opened this request when someone noticed that the lunar calculations in my software were incorrect, and this happened after I started using delta-t = 0.
That's why I took your recommendation from reference #904 and changed all my software, to use the UT1 time scale as both input and output. So I completely eliminated my use of the delta-t = 0 setting.
But still I think the correct time scale is that a local transit of the Sun at Greenwich on an annual average should be at 12:00:00 whereas when I use the UT1 time scale a local transit at Greenwich in year 2 on an annual average is at 12:00:21 (in year 500 at 12:00:11 ;and in the year 800 at 12:00:06) meaning the biggest difference is in very early years.
The annual average local transit in Greenwich, I calculated according to the plan I brought in #904, except that I changed the time scale to UT1.
And yet regarding the years 1972 to 2072 I did use the UTC time scale because in these years it does not ignore delta-T. The year 1972 as a start - you wrote to me, but you did not write until which year UTC does not ignore Delta-T. I just chose the year 2072 because I thought that maybe by then the leap seconds could be counted on.