Internally, mounts operate on UTC time only and don't care about/know about silly constructs such as DST and time zones. I would pull the session's logs from whatever imaging or sequencing program you're using and APCC, if you're using that.
toggle quoted messageShow quoted text
I've seen funny things with lots of programs over the years regarding their reaction to DST changes, the start of DST in particular. A typical scenario is a program monitors IO for timeouts based on local wall clock time, and not seconds elapsed. Suddenly time jumps forward 1 hour and the program is convinced that it hadn't heard anything for an hour, and reacts in an improper way.
On Mar 15, 2021, at 00:25, Jim Fakatselis <email@example.com> wrote:
Last night I was imaging with my QSI683 camera through the AP 130EDF on my Mach1GTO and had an unusual thing happen. I was on my last subframe of the evening, at around 2am and suddenly I noticed that the guiding errors grew tremendously.
I noticed the guide star was out of the field so I grabbed an additional full frame exposure through the guide camera to see what had happened. A 5 sec exposure showed stars streaking in the field of view, like the tracking was incorrect or even off.
After closer inspection I noticed that the mount parked itself at exactly 2:00am when the PC's clock automatically advanced from 2:00am to 3:00am during the EST to DST transition. It wasn't too much of a problem since I was closing down for the night anyway, so I lost the 10 min subframe.
I was wondering why/how the mount automatically parked due to that sudden time shift Any ideas? Anyone else had this happen to them?
Peppermill Skies Observatory