Summary: | Moon rise and set information wrong | ||
---|---|---|---|
Product: | [Applications] kstars | Reporter: | David Houlden <djhoulden> |
Component: | general | Assignee: | Prakash <prak902000> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alexey.skladnoy, mutlaqja, prak902000 |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: |
Whats Up Tonight showing moon rise and set times
Object details showing different set time Another screenshot of Whats Up Tonight |
Description
David Houlden
2009-10-25 13:34:42 UTC
Is there mistake in your bug report? It seems that rise/set time in details dialog are correct but than you state that it's not. Rise/set time is consistent in detail dialog and what's up tonight in 4.4.4 and trunk. I didn't tried to use 4.3 though. Could anyone reproduce the bug? Created attachment 48084 [details]
Whats Up Tonight showing moon rise and set times
Created attachment 48085 [details]
Object details showing different set time
I have also moved on to 4.4.4 since reporting this. However, the set times are still inconsistent. I've attached a couple of screen shots to show the problem. One shows a set time of 12:13 am while the other shows 00:29. Created attachment 48118 [details]
Another screenshot of Whats Up Tonight
Here is a screenshot showing another problem I see today in What's Up Tonight. The moon rise time is shown as 11:19 am on Friday 18 June. The moon set time is 11:30 pm on Saturday 19 June. That means the moon is above the horizon for over 36 hours without setting which is not correct.
I fixed this in trunk yesterday. BTW, was the other problem due to the moon set time of the next day being shown instead? (In reply to comment #7) > I fixed this in trunk yesterday. BTW, was the other problem due to the moon set > time of the next day being shown instead? I have compiled kstars from trunk and am observing the following problems. The moon set time is still wrong in the object details window. I think you are right, it is showing the set time of the next day. The moon set time in What's Up Tonight is now correct until I change the date to a future day. The setting time shown for a day in the future is the time for a day earlier than it should be. Rise/set times are calculated in 3 places: KSPopupMenu, detail dialog and WUT dialog. Methods to account for rise on the next day are different in each place. I think that right way to fix it is to fix to fit code in SkyObject. I have no idea how to get time for the right day. This could be cause of bug #179389 as well Its not exactly computed in WUT, its computed in KSAlmanac - which stores rise-set times of the Sun and the Moon. It by default computes the rise time of the next day, and set time in the current/next day. The code used for computing the Rise/Transit/Set times in KSAlmanac "seems" to be doing the right thing, I tested it for different dates. (I used http://www.timeanddate.com/worldclock/moonrise.html to verify the times) David, are you sure there's something wrong with the set time in WUT when you change the date? If yes, I think I know where the bug is. Okay, I found the bug in Detail dialog, it just looks at the value of the times of rise and set times, and looks for set time in the next day if its value is lower. But the riseSetTime() function in SkyObject seems to take care of this by itself. So, the next day's time gets displayed instead. (In reply to comment #11) > David, are you sure there's something wrong with the set time in WUT when you > change the date? If yes, I think I know where the bug is. Yes, it definitely looks wrong to me and I've checked against the times given by http://www.usno.navy.mil/USNO/astronomical-applications/data-services/rs-one-year-us You can try it yourself. With WUT open, click on "Change Date" and change it to tomorrow. Moon rise time seems to be correct but the set time is wrong. Same for any date in the future. Hmm, weird, its place dependent then. It updates fine for me though, what's the location setting that you're using? (In reply to comment #14) > Hmm, weird, its place dependent then. It updates fine for me though, what's the > location setting that you're using? Cambridge, United Kingdom I see, the times are offset by a day and an hour at times, or just an hour at times. Is there some DST involved here as well? Yes, DST is involved. You should maybe look at bug 209647. I follow the procedure described there to get the clock set right when I start kstars. I'd like to point that there is definite problem in the SkyObject::riseSetTime* functions. They return QTime but time without date make little sense. One have to start guessing date and obviously he will get it wrong in some cases. Functions should return both date and time (KSDateTime). Such modification could solve some of problems at least. Right, I was thinking of the same as well, we end up doing a lot of guesswork on the date. Will look into this soon. Looks like the issue is fixed in recent KStars versions. Just verified with multiple sources and rise/transit/set times are accurate. Please reopen if you experience the issue again in the GIT version (v.2.3.0) |