Detail window has incorrect transit time STEPS TO REPRODUCE 1. Stop simulation, set geographic location to 48°13/-1°42, time and date to 2018/11/02 02:16am 2. Check south, locate Zaurak in Eridanus, open details for this object 3. Open position tab in the detail pop-up OBSERVED RESULT Transit time is indicated at 02:16am, but Zaurak Hour Angle is 4'52 minutes east of local meridian at that moment. EXPECTED RESULT Transit time indicated at 02:20am. SOFTWARE VERSIONS (available in About System) KDE Plasma Version: - KDE Frameworks Version: 5.38.0 Qt Version: 5.9.1 ADDITIONAL INFORMATION
I found this while rewriting the planning algorithm of the Scheduler. #267265 is similar, but fixes an issue deeper in the calculations. Calculating transit time with KNumbers gives proper results. The issue seems to be in the way the details pop-up consolidates the target coordinates. The call to updateCoords is dubious. Tested with Stellarium supports the issue claim, as in the same geographic and time conditions transit time is 02:20 there too.
Okay, any idea on what is causing this?
No yet. Preliminary guess is that while calculating, the algorithm incorrectly moves to a different day, which offsets the transit time by 4 minutes.
So I just checked with SkyCharts & Stellarium. There is no consistent results. Time varies anytime between 1-5 minutes. Sometimes, KStars & SkyChart agree but differently from Stellarium, and sometimes it's the opposite, and sometimes SkyCharts & Stellarium agree but different from KStars. There is no consistency at all for more than 10 different objects tested. It's not simply a matter of 1-day off offset.
Sure. I was only referring to the 4 minute offset. Actually I do not compare softwares to prove which is right and which is wrong: this is bug is only about the fact that the transit time presented in the dialog doesn't result in the object being at the meridian at that moment. D16429 has an algorithm for culmination that is compatible with what is drawn by KStars, so we could use that to debug the dialog code and see at which point the execution diverges. Now, which computation is the correct one is another story.
*being at the meridian at that moment on the chart that is drawn on the screen.
This is quite similar to the moon transit bug, I think the algorithm is faulty.
Git commit a9b1d5a220a5b038a41f157d5db0be708b68bb23 by Jasem Mutlaq. Committed on 14/09/2021 at 10:06. Pushed by mutlaqja into branch 'master'. Fix transit and set times for several types of objects. Only remaining problematic object is comets. Lunar, Solar, Planetary, and Stellar objects rise, transit, and set times confirmed from multiple sources. Related: bug 438591 FIXED-IN:3.5.5 M +46 -45 kstars/dialogs/detaildialog.cpp M +7 -10 kstars/skyobjects/skyobject.cpp https://invent.kde.org/education/kstars/commit/a9b1d5a220a5b038a41f157d5db0be708b68bb23