<div dir="ltr"><div dir="ltr"><div>In addition to these issues, looks like we also an issue with the Sun's diameter as reported here: <a href="https://bugs.kde.org/show_bug.cgi?id=497129">https://bugs.kde.org/show_bug.cgi?id=497129</a></div><div><br></div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>--</div><div>Best Regards,<br>Jasem Mutlaq<br></div><div><br></div></div></div></div></div></div><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Dec 6, 2024 at 10:45 PM Akarsh Simha <<a href="mailto:akarshsimha@gmail.com">akarshsimha@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Hi Hy,</div><div dir="auto"><br></div><div dir="auto">On the contrary, this is the behavior I would expect of the method in the KStars pop up menu and details dialog. Relatedly, the bug reported by Giovanni on the mailing list through the YouTube video may be because transit time is not behaving like this — it’s instead always predicting the next transit. For the Sky Map use case, I would want the method to produce the closest occurrence to the given time — past or future.</div><div dir="auto"><br></div><div dir="auto">You’re right that this is not what we want always. </div><div dir="auto"><br></div><div dir="auto">But I presume your use case here is to show the moon’s interference in the night in the imaging planner. Then, isn’t this exactly the behavior you want?</div><div dir="auto"><br></div><div dir="auto">I could be wrong in understanding here; but I’m think if the moon is up at midnight + 1 minute, you would want to show a band from the previous rise (happened on someDay - 1) and the next set (happening on someDay). One of the two, rising or setting would likely be during the day so your moonshine band would run either from the rise time all the way into morning twilight or from the evening to the set time.</div><div dir="auto"><br></div><div dir="auto">Similar if the moon is not up and rising — you want someDay’s rise for this application. You don’t care about the set time.</div><div dir="auto"><br></div><div dir="auto">Finally if the moon is not up and setting — you want someDay’s set time and not interested in the rise time.</div><div dir="auto"><br></div><div dir="auto">How else should the API be structured in your opinion? What is the expectation? I ask because if you want the moonrise and moonset on a particular calendar day (from 00:01 to 23:59) then there are days when there is no moon set (because the moonset happens on the next day) or days when there is no moon rise.</div><div dir="auto"><br></div><div dir="auto">Regards</div><div dir="auto">Akarsh</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">On Fri, Dec 6, 2024 at 01:00 Hy Murveit <<a href="mailto:murveit@gmail.com" target="_blank">murveit@gmail.com</a>> wrote:<br></div><div dir="auto"><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Akarsh (and FYI Jasem),<div><br></div><div>I can see some issues in kstars/skyobjects/skyobjects.cpp</div><div>Please look at comments on line 100 and line 116 (they were written by you Harris and you/Akarsh back in 2004 and 2009).</div><div><br></div><div>When we ask the almanac for rise and set times on a given "midnight", it either goes ahead 12 hours if the object's AZ < 180 or goes back 12 hours hours if the AZ is > 180, and then </div><div><br></div><div>this next method has the comments</div><div><br></div><div> // We iterate once more using the calculated UT to compute again<br> // the ra and dec for that time and hence the rise/set time.<br> // Also, adjust the date by +/- 1 day, if necessary<br></div><div><br></div><div> // By adding this +/- 1 day, we are double-checking that the<br> // reported rise-time is the _already_ (last) risen time, and that<br> // the reported set-time is the _future_ (next) set time<br></div><div><br></div><div> // However, issues with this are taken care of in<br> // SkyObject::riseSetTime()<br></div><div><br></div><div>So, assuming the code is accurately following the comments, then the semantics of the calls to KSAlmanac::moonRise(), moonSet(), getMoonRise(), getMoonSet() when KSAlmanac is constructed with midnight on a given date are complex...depending on if the moon is up or not.</div><div><br></div><div>Working this out and trusting the comments, then if the moon is up, then the reported times are the previous rise and the next set.</div><div><br></div><div>However, if the moon is not up and rising the the rise is the next rise and the set is the set after that.</div><div><br></div><div>But if the moon is not up and going further down, then the is the previous rise and previous set.</div><div><br></div><div>So putting this all together, it seems to me that if I ask for a particular day's rise set by calling with KStarsDateTime(QDate(someDay), QTime(0, 1)) -- one minute after midnight on 'someday', then I may get:</div><div><ul><li>someDay-1's rise and someDay's set (if the moon is up)</li><li>someDay's rise and someDay's set (if the moon is down but rising)</li><li>someDay-1's rise and someDay-1's set (if the moon is down and going further down)</li></ul><div>All that is certainly not what I was expected when coding the imaging planner (really the moon graphics on the alt-vs-time plot). </div></div><div><br></div><div>It is possible that these semantics make sense for some aspect of KStars, but we should probably clarify the semantics of the APIs and likely add some new ones for situations like mine.</div><div><br></div><div>Now that I understand that, I could try and fix that for my special case, but this is really an issue with SkyObject and any code that winds up calling the SkyObject::riseSetTime methods.</div><div>Do you have time to take a look and let me know how you think we should proceed?</div></div><div dir="ltr"><div><br></div><div>Hy</div><div><br></div></div>
</blockquote></div></div>
</blockquote></div></div>