Local Mean Solar Time doesn't work in Qt6 version

[worachate001]

Expected Behaviour

Time zone changes according to longitude of current location.

Actual Behaviour

Time zone = UT

Note: Testing Stellarium 1.22.2 by building it in my machine (AppImage in the development snapshot appears to not working). Local Apparent Solar Time also affected.

Steps to reproduce

1. Open Location window
2. Set the Time zone to Local Mean Solar Time

System

• Stellarium version: 1.22.2
• Operating system: Linux Mint 21

[alex-w]

I cannot confirm the issue on macOS

[gzotti]

Current master: works on Windows.

[axd1967]

(@worachate001 I guess you mean 0.22.2 rather than 1.22.2; there is no such version AFAIK?) -> ok, see 3d47d9a4ff; maybe this should be tagged e.g. 0.22.3-1 or 0.22.3-alpha etc, see SemVer; 1.22.2 would not be a good choice! maybe 1.0 then...)

I'm aware my comments are unlikely to be appreciated for various reasons, and have no special place in this issue, and I certainly don't want to be negative (despite the impression the team has of me), but IMHO the - dearly needed - Qt6 version should remain far longer in a separate (development) branch so that it can be tested far more extensively. Qt6 dev seems to have started 2022-03-31 (with e90614ea532805e6150e35351c575d4962f306c8, after an abandoned attempt in 2020-12: 73d054c2f53fda3a725028d46847d37cf90f9639), I'm not surprised it takes a long time before migrating to Qt6; this depends on a lot of factors, one being the lack of sufficient developer resources. So it takes courage to jump to Qt6 ... but maybe patience might pay off more.

Meanwhile, normal Stellarium evolution on master could continue with new features etc; once there is enough indication that Qt6 is mature for Stellarium, then only should the jump to Qt6 be made.

Because now Qt6 is "polluting" the master branch; there is a considerable risk, as issues start to pop up to prove this. A lot of experimental things has been going on in the master branch; these fixes and trials belong in a separate branch.

I - but who am I - recommend to revert to a point before Qt6 was introduced (e90614ea532805e6150e35351c575d4962f306c8 as far as I can see), and develop a specific Qt6 branch that must be extensively tested before release. I'm aware it could be very difficult to revert all these changes... But all is not lost, as 0.22.2 is a good starting point to continue a master branch e.g. master-qt5, and from which 0.23 etc can be published. This is the same approach that was recommended in https://github.com/Stellarium/stellarium/pull/1816#issuecomment-890382301.

Any Qt6 work should remain well separated from ongoing (Qt5 based) improvements such as e.g. b7e4977f48097d99822985fb99c401f4fca2843e, 659966160c07f015905a87ee02638a6db8598ed1, 015b152c744770541200c883953832fb536bc33f or 95bfe864b8244bc049fb29053c7e4b53df84945c, dbd0a3c53e5b1e04599b96539e126124cda5ebc1 (just some quick easy picks). In other words, bugs and new features should be solved in the "Qt5" branch (= current master) and systematically merged (and tested) in the Qt6 branch. This way, the Qt6 branch remains "primed for launch" and when it is cleared for release, it should be relatively trivial to merge to the master branch.

This illustrates a typical issue in software engineering - dealing with migration paths, a dreaded task that is often - and understandably - put on the back burner as long as possible (rather than as soon as possible). Again, 73d054c2f53fda3a725028d46847d37cf90f9639 was a good moment to start Qt6, and illustrates several issues.

In short:

1. create a master-qt5 branch (from 0.22.2) that becomes the "main" branch (also on GitHub),
2. pick all the changes that were mixed in the current master branch,
3. and create a master-qt6 branch (or simply qt6) from the current master branch.
4. all bug corrections and new features (that do not depend on Qt6) are applied on the master-qt5 branch and then merged to the qt6 branch
5. ask enough developers to extensively review, compile and test the Qt6 branch

Sorry for the critique, I'm also aware that I cannot offer a good alternative, but I do worry sometimes of the approach taken.

@Atque @xalioth @alex-w @gzotti @matthewg42 @cardinot @guillaumechereau @treaves @worachate001 @ultrapre @A-j-K @Jocelyn1109

[gzotti]

After ensuring the program can be built and run with Qt6 we have merged and there is again one master that can be compiled with Qt5 to build versions 0.22.* and Qt6 to build 1.22.*. Simply don't bother with that until September while we are identifying problems. Some problems (e.g. #2544) now discovered are not even related to Qt6.

[gzotti]

Bohoo. Confirmed on Ubuntu 22.04. So this is a Linux specific issue.

[github-actions[bot]]

Hello @worachate001! OK, developers can reproduce the issue. Thanks for the report!

[gzotti]

StelCore.cpp L1285: tz("LMST") should not be valid. For whatever reason it seems to be valid in Qt6.3 on Linux.

[github-actions[bot]]

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

[github-actions[bot]]

Hello @worachate001!

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

[github-actions[bot]]

Hello @worachate001!

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