Stellarium does not take into account leap seconds?

[pedrokkrause]

Stellarium seems to not take into account leap seconds. This can be seen by the fact that leap second dates don't exist (for example, 2016-12-31T23:59:60) and this script also shows the problem:

core.setDate("2000-01-01T00:00:00");
var JD1 = core.getJDay();
core.setDate("2024-01-01T00:00:00");
var JD2 = core.getJDay();
var dt = (JD2-JD1)*86400;
core.debug(dt);

It returns 757382400 seconds between these two dates, when it should be 757382405, considering leap seconds.

[gzotti]

No, we don't have a table of leap seconds. Can you describe where this hurts? (The respective time offset for ephemerides is handled by ΔT)

[pedrokkrause]

If leap seconds are not considered, then the time on Stellarium is not actually UTC, and everything has a systematic error of 37 seconds (you can check this number by using the script I provided with an older t0 and comparing with the true value) which is the difference betwen TAI and UTC. 37 seconds can be very relevant, as it can mean a 0.15 degrees difference due to Earth's rotation.

[10110111]

You can use core.getDeltaT() to get ΔT (in a string form, so you need to parse it to get a number). Find the difference between these values, and add to the difference between JDs to get the more correct value. It may vary depending on the ΔT algorithm being used (this setting is also available via the API).

[gzotti]

even core.getDeltaTsec() is available. So, in order to compute "physical" (ET/TDB, we make no difference here) seconds between two dates, you could need

core.setDate("2000-01-01T00:00:00");
var JD1 = core.getJDay();
var DT1 = core.getDeltaTsec()
core.setDate("2024-01-01T00:00:00");
var JD2 = core.getJDay();
var DT2 = core.getDeltaTsec()
var dt = (JD2-JD1)*86400 + (DT2-DT1);
core.debug(dt);

DT2-DT1 should be the approximate number of leap seconds between the dates.

[pedrokkrause]

The main issue is not about calculating the difference between dates (although this could also be a problem). If leap seconds are not considered, then there is a multiple seconds time delay between the positions of bodies in Stellarium and real life, which could be as much as 37 seconds, as mentioned, corresponding to an error of 0.15 degrees.

[gzotti]

Please give an example between published data (USNO, HM Nautical Almanac or similar) and Stellarium data deviating by such or similar amount.

[worachate001]

It's true that displaying leap second is not implemented in Stellarium (we cannot display 23:59:60), but we use ΔT to keep it very close to UTC. Technically, Universal Time in Stellarium (and other planetarium programs) is UT1, which agree within 0.9 seconds with UTC.

[pedrokkrause]

While I understand there exists Delta-T to account for Earth's variable rotation, let's go through an example and please clarify if my reasoning is wrong.

Suppose it is now December 31, 2016, 23:59:59 UTC. A leap second is about to happen. So, after 1 second, we are at 23:59:60, and after another second (2 seconds) we are at January 1, 2017, 00:00:00. Therefore, the difference between the position of objects between the initial time and now is around 30 arcseconds (because Earth rotates roughly 15 arcseconds per second).

However, let's now consider Stellarium, and we'll assume it is giving accurate values of celestial bodies positions at December 31, 2016, 23:59:59 UTC. Now, if I add 1 second to the software's clock, it will be now January 1, 2017, 00:00:00, but in this case only 1 second has passed. The position of objects will only have changed 15 arcseconds, not 30. And this error accumulates with each new leap second.

This is the issue I want to point out. If my reasoning is correct, this means Stellarium does give correct results, but not in the intended time scale (UTC) but in a different time scale (an UTC variant without leap seconds).

[worachate001]

Please consider this for the main topic:

• Stellarium is actually using UT1 (not UTC), I agree that we shouldn't use UTC, just call it Universal Time (UT) like in JPL/Horizons.
• ΔT = TT − UT1
• Terrestrial Time (TT) = TAI + 32.184 seconds, where TAI is UTC + (leap seconds)
• TT = UTC + (leap seconds) + 32.184 s
• ΔT = UTC + (leap seconds) + 32.184 s - UT1
• ΔT = (leap seconds) + 32.184 s − ∆UT1, where ∆UT1 = UT1 − UTC

So, leap seconds are already taken into account by using ΔT.

[gzotti]

I understand what @pedrokkrause wants to say. I just want to know, asking for examples, where it hurts anyone, when we try to fulfill ephemerides to the closest second. Stellarium is not the software certified for live-guiding spacecraft or control time-critical physical experiments. We use symbols Qt::UTC and Time zones are retrieved from system libraries as "UTC±offset". I cannot remember having seen the Qt documentation discussing leap seconds. Do we have to parse and patch all names? I was not able to find in a short time if ours is really UT1 or yet another unnamed variant. If anybody can write, for the 20 critically interested users, a paragraph about what our time actually is for the User Guide, we will clarify it.