So this is the first time I will be imaging during a DST/GMT kick in, so my target is currently set to finish at 04:15, and the sequence will start before DST kicks in, so will SGPro automatically adjust the end time when DST kicks in or will my imaging sequence have 1 hour less since we are moving to 1 hour ahead?
It will not. SGPro does not know anything about time changes for standard and daylight times. They are a nightmare to track and vary wildly by geographical location. It’s a lot of code for something that is a minor inconvenience, but more importantly, compensating for it would make all other time dependencies a lot more fragile (because they become a lot more complex).
So are you saying I should adjust my end time of the target +1h, or will the global “End imaging” time of 05:15 be sufficient, as that will go off the system time correct?
All time checks go off of system (current time)… even the individual target times. You only need to account for it in the target that will be running so that it doesn’t image an hour longer than expected. The sequence end time is the same.
ok cool, so I will leave the target with an end time of 06:15 for example, but global end time is 05:15, so imaging should stop at 05:15 BST (currently in GMT intil 1AM)
At least the planning tools graph seems to be taking GMT and BST into account
It’s possible I don’t understand exactly what your plans are, but it seems like you’d want to set all end times +1 hour. In the scenario above, if the sequence end time is set for 5:15 daylight time, the sequence will stop at 4:15 standard time because it will hit the sequence end time an hour faster.
Will it though? As End time goes off current system time correct? So if the system changes from 1AM GMT to 2AM BST at 1AM, then the end time is not based on GMT or BST right, it is based on System Time, so if I set this option:
That’s based on System time, irrelevant of BST or GMT right? Or does it define the end time at the beginning of the sequence?
I’m awake in the UK at 03.00 enjoying the last few nights clear sky. Remarkably this is the first time I’ve had clear skies to image on a GMT/BST change in the last decade. Here are my observations (and analysis of events but I have only made a cursory glance at logs - it is now 4am!! - so I don’t have exact conclusions) having roused myself from sleep to check on sequence progress in my backyard observatory (it’s cloudy in Spain so my shared remote rigs are not imaging).
The equipment for me is especially sensitive to hour change because of unguided imaging using a 10 Micron GM1000HPS which relies on accurate time input; and also for observatory control a Cloudwatcher/Lunatico Solo combination for weather safety reporting (& if a time differential is introduced the Cloudwatcher reports unsafe even if the actual weather conditions are safe).
So when I woke up to check progress - my mount was parked and equipment was disconnected and warmed, my observatory roof was open. Normally, the slave option would park the telescope first and then close the roof. The observatory had closed down at 2.00am (this is the BST time, so it was 01.00 UTC which for my location is GMT), the time when the change from GMT to BST is scheduled (it was 6 mins partway through a 10 minute lum sub started at 01.54 GMT). SGP’s log had reported an unsafe weather condition. Examining the Cloudwatcher/Solo graph, there is a break in the data graphical display equal to one hour between 01.00 and 02.00, ie the graph jumped forward one hour. At this point in time, my scope would be one hour adrift of the local time signal as I have to manually change time and switch to Daylight Saving Time. I think there was a momentary loss of connectivity to the mount at the time of the unsafe alert (due to the time change) causing the scope to become unslaved from the roof, hence the roof did not close. The Dragonfly also runs an internal clock and I wonder if it’s own GMT/BST time transition caused an issue. I have had LAN connectivity problems in the past due to the LAN socket and RPi board failing and one symptom was the roof becoming unslaved from the scope, though in this instance the Dragonfly log does not report a disconnect & neither does SGP’s log.
I have the relay on my Cloudwatcher connected to a sensor on the Dragonfly controller and if there is an actual unsafe weather alert the relay closes causing the sensor to change state and trigger a script that after 3 minutes checks to see if the mount is parked and roof closed, if they are not it will park the mount and then close the roof. This safety backup script has not been triggered because the Cloudwatcher would have reported safe within the 3 minute countdown, it’s unsafe was almost instantaneous as the graph jumped forward an hour. If I hadn’t woke to re-start the sequence after changing the mount’s DST setting, at dawn the Cloudwatcher relay would have closed and the roof would then have closed after my watchdog script was triggered.
So, a manual intervention was required for me to re-start the sequence due to the various systems and their interaction. I did have to move forward the sequence end time by one hour too ;-).
CS to you all 
So far so good
It worked, setting the end time of 5AM finished at 5AM BST 