I came back to KStars/Ekos/INDI just a couple of weeks ago.
Present Problem:
The KStars star map is 1h (15°) late with respect to the meridian. I.E. the hour angle of every object on the star map is off by -1 h.
I checked the system time/date information using the timedatectl command that gave correct values:
=> timedatectl
Local time: So 2018-09-30 16:05:01 CEST
Universal time: So 2018-09-30 14:05:01 UTC
RTC time: So 2018-09-30 14:05:01
Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes
systemd-timesyncd.service active: yes
RTC in local TZ: no
Local time as shown in the upper left corner of KStars is identical to the above local time from timedatectl.
The geographic location settings in KStars are
UT offset: 1 (which is correct ignoring the Daylight Saving Time DST
DST rule: EU (European union - which is correct as well)
There is no GPS device involved and the INDI tab in KStars settings has "KStars updates all devices" marked.
My mount controller (Astro-Electronic FS-2) does not communicate date/time to KStars
So, where is the cause of my problem?
I would be glad if anyone had any suggestion for me
Hi Eric,
thanks for replying that fast.
.My mount is parked at the meridian at DEC 0° and synchronized with KStars at that position. Comparing the actual sky with the sky map of KStars already showes the offset.
.Well, at first look: yes it did. My location is 8° 30' east of Greenwich which I entered as -08 30 in the KStars location settings (as used to from other software).
Considering Your second question it struck me that if the minus sign was ignored the result would be the sky view shifted in KStars by about 17° which would result in an correct view.
Playing around with the longitude value in the locations settings I finally recognized that positions east of Greenwich are not indicated by a minus sign - that's all. Problem solved - Just another user error.
.
It might be a good idea to supplement the longitude tooltip with something like "Locations west of Greenwich must be prefixed with a minus sign"
Yes I see what you mean. The use case behind the design is that end-users would first configure a location in the list that is close to their real location. In a second session, they would refine the location and adjust the position to create a new customized location. With that use case the sign is obvious.
Now, the coordinate fields could get a customized tool tip to provide this information, agreed. Currently the widget is the standard degree/hour gadget, and it's default tip is about how to format the entered value. You may also observe that it doesn't honor locale for decimal numbers.
Thank You, Eric, for clarifying.
And yes, sometimes user don't behave as expected - I ought to know after having developed user applications for some years long ago.
CS
Michael