change form UTC to LMST

Bug #1652763 reported by Victor Reijs
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Stellarium
Fix Released
Low
Alexander Wolf

Bug Description

Why is the displayed time in LMST before 1847CE? I state in Configure, that the program needs to use the system method, so why change that behavior when going earlier than 1847CE?

All the best for 2017,

Victor

Tags: time tz

Related branches

Revision history for this message
gzotti (georg-zotti) wrote :

Hi Victor!

We decided the use of time zones makes no sense before introduction of time zones. This should prevent mistakes when checking old observation records which in all likeliness were written in local mean solar time.
We have also disabled the global (Bortle) light pollution before 1825 when public outdoor lighting did not matter too much.

Hmm, but yes, there seems to be something strange. My LMST can be set to UTC+1 and still displays LMST. OK, it seems some minor issues still to be solved. And it certainly makes sense to have UTC (GMT) available regardless of location.

Changed in stellarium:
status: New → Confirmed
importance: Undecided → Low
Revision history for this message
Alexander Wolf (alexwolf) wrote :

Wait, are you want use custom time zone settings when he is enabled?

Revision history for this message
Alexander Wolf (alexwolf) wrote :

Fixed in revision 9026 (trunk)

Changed in stellarium:
milestone: none → 0.15.2
assignee: nobody → Alexander Wolf (alexwolf)
status: Confirmed → Fix Committed
tags: added: tz
tags: added: time
Revision history for this message
Victor Reijs (web-victor-reijs) wrote : Re: [Bug 1652763] Re: change form UTC to LMST

Hello Alexander.
I have not 'Use custom time zone' ticked in the location window.
I have in Navigation window 'System date and time' checked. And my system
date and time is based on GMT (Ireland; at this moment no summer time).

Perhaps having the option to use LMST would be good (I can also see the
merit of that one). But I understand the paradox you have. Everyone might
want a different system, but I like consistency in the interface (and no
automatic changes that users might also not understand).
I think it would be good to also show in the Date/time window also what
time is being used (incl what calendar type is being used).

And perhaps I would use x:xx LMST (UTC+x.yz) (instead of 'x:xx UTC+x.yz
(LMST)'). But again this is perhaps depending on what one uses.
Also remember you use Astronomical year instead of calendar year, which is
also something a lot of people have errors with when using Stellarium (even
archaeoastronomy experts;-).
I like the help when hovering over an area (like the DE431, where you
state that it is still experimental), perhaps that can also be used to
provide help in these timing/dating issues...
Another option is to provide the user with a window here he/she can specify
all these time/date issues and state it can be automatically changed or
not...

Again I can understand the paradoxes and the multiple directions specific
users will want to drag Stellarium.

Hope this helps.

All the best,

Victor

On 27 December 2016 at 15:15, Alexander Wolf <email address hidden>
wrote:

> Wait, are you want use custom time zone settings when he is enabled?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1652763
>
> Title:
> change form UTC to LMST
>
> Status in Stellarium:
> Confirmed
>
> Bug description:
> Why is the displayed time in LMST before 1847CE? I state in
> Configure, that the program needs to use the system method, so why
> change that behavior when going earlier than 1847CE?
>
> All the best for 2017,
>
>
> Victor
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/stellarium/+bug/1652763/+subscriptions
>

Changed in stellarium:
status: Fix Committed → In Progress
Changed in stellarium:
status: In Progress → Fix Committed
Changed in stellarium:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.