AstroCalc: Fix RTS

[worachate001]

Description

The problems are:

• Stellarium calculates RTS of the Moon by choosing the nearest instances. Sometimes, rise or transit or set time occurs on previous day or next day.
• There are time spikes in AstroCalc's RTS table which is a remaining issue in transit time incorrect on days changing from/to daylight saving time #1482 (near bottom of the page).

This PR will fix them by:

1. When select the Moon (or other objects). Info will show '(previous day)' or '(next day)' after the time to inform us that the calculated event doesn't happen on current day.
2. RTS table in AstroCalc will show the events that occur on the same date in the same row. This should make it easier to read/process in other applications.
3. Fixing above helps us eliminate time spikes issue.

Fixes #2990 and remaining issue in #1482

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• This change requires a documentation update

How Has This Been Tested?

Test Configuration:

• Operating system: Manjaro 22.0.1
• Graphics Card: -

Checklist:

• My code follows the code style of this project.
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (header file)
• I have updated the respective chapter in the Stellarium User Guide
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[github-actions]

Great PR! Please pay attention to the following items before merging:

Files matching src/**/*.cpp:

• Are possibly unused includes removed?

This is an automatically generated QA checklist based on modified files.

[alex-w]

Thank you very much for the fix!

I see sentences “previous day/next day” - why not “yesterday/tomorrow”?

[10110111]

I see sentences “previous day/next day” - why not “yesterday/tomorrow”?

It makes sense if current day is not the realtime "today", and not even a simulated "today".

[worachate001]

Thank you very much for the fix!

I see sentences “previous day/next day” - why not “yesterday/tomorrow”?

This actually came across my mind at one point during development. But I though the same with @10110111 that it's mostly simulated time. Using yesterday/tomorrow may not make sense.

[alex-w]

This actually came across my mind at one point during development. But I though the same with @10110111 that it's mostly simulated time. Using yesterday/tomorrow may not make sense.

OK, I got it

[gzotti]

Many thanks for this. StelObject::getInfoMap() may be fixed with this update too. The transit, rise and set entries are QStrings which may have (previous day) or (next day) appended (I think we usually don't translate the InfoMap to make it easier for programs which are using it). I am not sure how to deal with the {transit|rise|set}-dhr entries, those are numerical. Allow hours >24 and <0? Or just keep as-is and let the user of the data find out by parsing the other string?

[worachate001]

Many thanks for this. StelObject::getInfoMap() may be fixed with this update too. The transit, rise and set entries are QStrings which may have (previous day) or (next day) appended (I think we usually don't translate the InfoMap to make it easier for programs which are using it). I am not sure how to deal with the {transit|rise|set}-dhr entries, those are numerical. Allow hours >24 and <0? Or just keep as-is and let the user of the data find out by parsing the other string?

I'm thinking about another way that might be better. Create getRTSTimeOfDate() that returns RTS of current date (doing it inside getRTSTime() may be too complicated).

[gzotti]

OK. Just that the InfoMap always needs updates in line with the InfoString.

[worachate001]

I'm ditching the idea of displaying 'previous day' or 'next day'. It was proposed earlier because that is an easy way with minimal tweak in existing codes. But it becomes more complicated for StelObject::getInfoMap().

New update will show RTS that occur on current date only (RTS will change at midnight, not seem to change in unpredictable way during a day like before). It also makes more sense and in line with the way they show RTS in astronomical almanacs. Please check StelObject::getInfoMap() to see if it's okay with new changes because I'm not familiar with its structure.

Update: Made it draft because there is a potential bug for non-solar system objects.

[alex-w]

Hmm... I see serious regress of performance on the Mac when the Moon is selected

[worachate001]

Thanks @alex-w. I have no performance hit so I'm not sure it's getting better or not. The new update should work now for all objects.

[github-actions]

Hello @worachate001!

The enhancement or feature has been merged into source code and you may test it via building Stellarium from source code or wait the weekly development snapshot...

[github-actions]

Hello @worachate001!

The fix has been merged into source code and you may test it via building Stellarium from source code or wait the weekly development snapshot...

[github-actions]

Hello @worachate001!

Please check the fresh version (development snapshot) of Stellarium:
https://github.com/Stellarium/stellarium-data/releases/tag/weekly-snapshot

[github-actions]

Hello @worachate001!

Please check the latest stable version of Stellarium:
https://github.com/Stellarium/stellarium/releases/latest