CEM60, Stellarmate on rPi4, updated nightly.  
I DO live in a DST country and this problem has plagued my meridian flips from day one.  The mount disagrees with Kstars when the flip tries to run.  

I DO get the wrong time in Kstars when I have DST set to Y in the HC, and have mount update time and location.

My workaround for this was to remove the HC from the mount, then everything works fine for the flip.

No issues with my EQM-35 Pro using the same system.

True! I've modified the title (honestly, I don't really know what to write there, so any idea to improve it even further is very welcome)

I've modified title since this is an iOptron issue only.

Hi,

if this is about time syncing for iOptron mounts there is definitelly is a problem. (Has been discussed in earlier topics)
I sync time from Kstars to the mount (cem60), and the only way to make it work correct is NOT to use DST in the mount, but set the time offset to include the DST.

The driver does not take into account the DST setting if set in the mount.

Probably caused by this
IOptron RS232 manualNote that in the shown response the DST flag is not shown but it is explained as the 4th digit (between offset and date)

the diver does not handle that:

Hi,

if this is about time syncing for iOptron mounts there is definitelly is a problem. (Has been discussed in earlier topics)
I sync time from Kstars to the mount (cem60), and the only way to make it work correct is NOT to use DST in the mount, but set the time offset to include the DST.

The driver does not take into account the DST setting if set in the mount.

Probably caused by this
IOptron RS232 manual
Command: “:GLT#”
Response: “sMMMYYMMDDHHMMSS#”
This command gets time related information. The response includes a sign and 16 digits.
The sign and first 3 digits indicate the minute offset from UTC (time zone). Note: The Daylight-
Saving Time will not be take account into this value.
The 4th digit indicate the Daylight-Saving Time, 0 means Daylight Saving Time has not been
observed, 1 means Daylight Saving Time has been observed.
The 5th to 10th digits indicate for current local date.
The 11th to 16th digits indicate for current local time in 24 hours format
Note that in the shown response the DST flag is not shown but it is explained as the 4th digit (between offset and date)

the diver does not handle that:Decoding dst is missing at res+4 (and probably handling as well)

if (sendCommand(":GLT#", res))
    {
        *utc_hours = DecodeString(res, 4, 60.0);
        *yy = DecodeString(res + 5, 2) + 2000;
        *mm = DecodeString(res + 7, 2);
        *dd = DecodeString(res + 9, 2);
        *hh = DecodeString(res + 11, 2)
       *minute = DecodeString(res + 13, 2);
        *ss = DecodeString(res + 15, 2);
Didn't check setting time , but probably same thing.

Rgrds,

Paul

I have this issue with a GEM45 (latest firmware) and ioptronv3 driver.

I’m GMT+1 with DST, and kstars is updated from the mount 1 hour earlier, i.e. as if DST is off. However, I have to stress that the issue is only related to the time displayed by ekos as Local Time. Sidereal time is correct, so no issue with slewing to target.
Also note that the driver log reports “DST is on”, so the response from the mount is properly parsed.

Nice catch! You may have found where the bug is  Thanks a lot PDB!!

EDIT: unfortunately, that doesn't seem to be our bug. CEM70 and others are using v3 driver, which now uses GUT instead of GLT, and the driver is correctly parsing the info: github.com/indilib/indi/blob/a6ffc654e24...driver.cpp#L709-L732

Problem also occurs in the CEM120 as well.

I just reset my observation site info in settings and it gets back in sync.

Thanks! Good to know that sideral time is correct
What's not working correctly due to this bug is autopark (could be workarounded by setting wrong time there). Dunno about meridian flip, this should be checked too (can't do it these days due to rain)

You mean in kstars or HC?

Any feedback from INDI Nightly release for those with the DST issue?

Having this issue, too, with my iOptron HEM27. Right, I am in DST (Taiwan). As observed, it's about 2 days off. Firstly I thought my RTC was broken but nice to know it is a known issue.
Is there any workaround at this point? This is annoying as I have to set the date and time every time I am going to capture.

Lucian