equinox in Alexandra at 140CE

TZ of Alexandria is UTC+2, TZ for my location if UTC+7.

I get DE=0 for Sun 140/3/21 in 17:24 on my TZ. When I change location to Alexandria, then DE=0 began in 17:21 (for my TZ), or 12:21 for Alexandria's time, or 10:22 UTC. DeltaT for 140/3/21 is 2:23:42 - 12:45 UTC without correction for DE=0.

Is SkyMap Pro 9 and SkyViewCafé known about DeltaT?

SkyMap uses Stephenson & Houlden (1986) and SkyViewCafe uses Chapront, Chapront-Touzé & Francou (1997).

Also someone looked for me at JPL DE422 ephemeris who got 0140-03-21 (Julian calendar), 16:46:30 TT. if you add DeltatT (around 2h 23min) one you get close to 14:23 UT. So close to SkyMap and SkyViewCafe.

So I don't think it is related to DelatT.

All the best,

Victor

Though not a solution, I think I know where the observed equinox timing error is occurring.

There seems to be an issue here which is not related to time zones or DeltaT. Assuming that "Without Correction" is meant to show Dynamical Time (TD) / Terrestrial Time (TT), then Stellarium's calculation of TD is not correct as it should be. For the year 140 equinox in question, the TD error between Stellarium and Horizons ~ 4 hours. The Horizons "TT" for this event is ~16:52, and Stellarium's "without correction" time ~12:41. This TD error accounts for the observed equinox error.

To look deeper, I then compared Stellarium equinox times to Horizons equinox times every 500 years between -2000 and +3000. I found the TD errors very nicely grew quadratically with time. The smooth, parabolic growth of the TD error suggests that it is algorithm related, not an simple time-zone offset. The details of this error curve are (I'd like to show my plot, but if that's possible):

=> TD Error = 21c²-1160.1c+16132, where c = centuries from year 0, and TD Error is in seconds.

So for c = 1.4, TD Error = 14549 seconds. The minimum TD Error of 110 seconds occurs in year 2762, while at year -1000 (c=-10), TD Error = 29833 seconds.

There is no doubt I'm seeing the same thing Victor is seeing, and if TD is represented by the "Without Correction", then there is an anomalous TD error occurring.

<I thought I had send already additional info yesterday, but seem not to see it anymore...>
I looks that at the above mentioned TT (16:46:30 or 14:23UTC) the related RA/DE (J2000.0) are very close to what is seen in DE422. So the J200.0 RA/DE is correct, the RA/DE (of date) is not correct. So the precession formula does not seem to be correct (I think that in the past (a year ago?) I also mentioned that [with a stellar example] and I don't know if that was ever solved)?

All the best,

Victor

Just some more detail:

At 140/3/21 14:23:21 UTC (with DeltaT 2h 23min) I have in Stellarium:
RA/DE (J2000): 1h35m49.3s/+10°06'04.4"
RA/DE (of date): 23h59m30s/+0°03'56"

 This is the info from DE422 (at 0140-03-21 (Julian calendar), 16:46:30 TT which is 14:23 UT) : 1h35m48.37s +10°06'00.6" GCRS RA & dec
So this looks quite close to the J2000 value of Stellarium, but the DE (of date) is not zero... So something with the precession model?

All the best,

Victor

Precession error seem to fit for this example, but another example does not.

Alexandria had a total lunar eclipse on 140-12-11. If there were a precession error, I'd expect the time and/or RA & Dec of date should show up in this case too. It doesn't.

From Five Millenium Canon of Lunar Eclipses:
Max Eclipse Time: ~17:17UT
Moon RA/Dec (of-date): 5h19m02s / +22°44'47" (from Alexandria)

From Stellarium:
Max Eclipse Time: ~17:13UT
Moon RA/Dec (of-date): 5h18m40s / +22°44'22" (from Alexandria)

Stellarium appears to predict the eclipse very well.

I don't see how there could be a precession error, but something is going on.

Just some other data from JPL HORIZON: (which gives comparable TT as DE422):
 Date__(TT)__HR:MN:SC.fff R.A.__(a-apparent)__DEC ObsEcLon ObsEcLat
*****************************************************************************
$$SOE
 0140-Mar-21 16:47:00.000 23 59 59.85 -00 00 00.2 359.9994174 0.0001909
 0140-Mar-21 16:47:10.000 23 59 59.88 -00 00 00.0 359.9995302 0.0001909
 0140-Mar-21 16:47:20.000 23 59 59.90 +00 00 00.1 359.9996430 0.0001909
 0140-Mar-21 16:47:30.000 23 59 59.93 +00 00 00.3 359.9997558 0.0001909
 0140-Mar-21 16:47:40.000 23 59 59.95 +00 00 00.4 359.9998686 0.0001909
 0140-Mar-21 16:47:50.000 23 59 59.98 +00 00 00.6 359.9999814 0.0001909
 0140-Mar-21 16:48:00.000 00 00 00.00 +00 00 00.8 0.0000942 0.0001909
 0140-Mar-21 16:48:10.000 00 00 00.03 +00 00 00.9 0.0002070 0.0001909
 0140-Mar-21 16:48:20.000 00 00 00.05 +00 00 01.1 0.0003198 0.0001909
 0140-Mar-21 16:48:30.000 00 00 00.08 +00 00 01.3 0.0004326 0.0001909
 0140-Mar-21 16:48:40.000 00 00 00.10 +00 00 01.4 0.0005454 0.0001909
 0140-Mar-21 16:48:50.000 00 00 00.13 +00 00 01.6 0.0006582 0.0001909
 0140-Mar-21 16:49:00.000 00 00 00.15 +00 00 01.7 0.0007710 0.0001909
$$EOE

Important note: precession is hard coded at the moment and has const value :(

Victor, as you suggested earlier, a lower-precision precession algorithm is the origin of the late 140 Equinox timing.

I've used Stellarium's J2000 North Celestial Pole coordinates over 5000 years (-2000 to +2900) and J2000 Sun coordinates (Stellarium and HORIZONS J2000 coordinates are VERY close) to calculate the Sun declination-of-date. Comparing these calculated declinations to Stellarium's declinations-of-date and HORIZONS' Sun declinations-of-date, I found near perfect agreement. I.e. Stellarium's declination errors do indeed arise from the precession error over time. Equinox timings are sensitive to declination error: ~1 hour per arc minute.

See https://answers.launchpad.net/stellarium/+question/244463

This explanation answers your question.

Jon

It would be nice if it could rectified. I understand it got the tag 'archaeoastronomy', but I think it is an astronomical issue...