Fig 1.  Convergence Plot  showing issue with retrograde changes in overall score of the Best Plan.

Aim
To make AstroSuite Programs  particularly live session operations using AstroMain, AstroPlan & AstroAllSky robust to DST changes.

DST changes occur twice a year in UK
- from GMT to BST at 01:00 on Last Sunday of March
- from BST to GMT at 02:00 on the Last Sunday of October

Images acquired in the observatory are timestamped with UTC date/time in FITS Header and the observations recorded on observatory website are annotated with UTC dates/times.  Where relevant calculations (such as time since a discovery date) are all in UTC. 
(AllSky images are annotated with both UTC and Local Times. 

However for console display, logging, charting and recording of plan observations, actual observations & session events  date/times are all in local time (labelled as such whereever possible.   This approach avoids confusion during the summer period (between March and October DST changes) where the UT time is one hour different from the local time. And for 363 days (nights) a year this works well . 

Since both DST changes occur at nighttime and may be during the the time period when Observatory nightime operation can be take place, the clocks going forward by one hour (March chnage) or going backward by one hour (October change) upsets the display of numerous charts and displays across the AstroSuite programs, which are annotated in Local Times.

Past Sessions involing a DST Change
Sessions which have active during a DST Change include the following

- S716 (2019-10-26)
- S821 (2020-10-24)
- S930 (2021-10-30)
- S996 (2022-03-26)
    (2022

Note: Sessions prior to introducing Targets DB aren't shown.

Past Issues associated with DST Changes

Past issues have been asscoiated with DST have been as follows.  The current status of each issue is shown as of 2022-09-08.

• S716 (2019-10-26)
• CloudSensor and Weather Data readings became anomalous for a 1 hour period at 02:00.
  To be fixed at some point (AstroWeather/AstroAllSky/AstroMain)
   
• Current Time Line on Website Charts (Observing Plan and Observing Results was being drawn at the wrong position.  Error varying from 15 mins too late to 30 minutes too late.   Problem was associated the end of Daylight Savings, with the night being one hour longer in local time than in UT time..
  Fixed  2022-09-06 (AstroPlan 1.32.2)
   
• Observing Plan does not handle the 'extra hour' when the clocks went back at 02:00.
  Fixed  2022-09-08 (AstroPlan 1.32.3)
   
• S821 (2020-10-24)
•  Cloud Sensor Data inactive for one hour period after clock went back at 02:00.
  To Investigate & Fix (AstroWeather/AstroMain).
   
• AllSky NightSummaryPlot is missing 02 h mark/label when clock went back at 02:00.
  To Investigate & Fix (AstroAllSky).
   
• AllSky NightSummaryPlot show low Stars Count for one hour period after clock went back at 02:00.
  Fixed 2022-09-26 (AstroAllSky 3.16.4)
   
• AllSky NightSummaryPlot show flatlined Clarity value for one hour period after clock went back at 02:00.
  To Investigate & Fix (AstroAllSky).
   
• S930 (2021-10-30)
• For the one hour period after clocks go back at end of daylight saving time, it isn't possible to set TheSky6 to the equivalent UT time.
  User Awareness  (TheSky6)
   
• AstroMain job execution hung at 01:59/02:00.  
  Fixed 2021-10-31  (AstroMain 3.45.5)
   
• The Red 'Current Time' line that is overlaid on the Observing Plan and Observing Results charts on current session web page is drawn at an incorrect position (DST Issue).
  Fixed  2022-09-06 (AstroPlan 1.32.2)
   
• On nights when clock changes as in the session S930 times of Sunrise, and rising Sun Altitude during the morning are incorrect on Schedule Builder Form and on Observing Plan/Observing Result Charts (DST Issue). 
  Fixed 2022-09-07 (AstroPlan 1.32.3) 
   
• Moon Altitude LIne on AltitudePlan Chart takes an unexpected step in altitude at the point where clock changes at 02:00  
  To investigate and fix/workaround. (AstroMain)
   
• S996 (2021-03-26) 
• No DST related issues mentioned in Operational Issues.
  

Current/Latest Session Web Page
Current/Latest Session web page (session_current.htm) draws a red vertical line on Observing Plan and Observing Results Charts to indicator the current time position.

It does this by reading the file 'live/Session.Charts.js' which contains the UTC times corresponding to the left hand and right side of the picture area. The .js file contains two lines and is created and uploaded to website by AstroPlan program at the start of session.
  window.T1 = new Date("2022-08-25T19:09:11Z");
  window.T2 = new Date("2022-08-26T05:11:44Z");
The 'Z'  suffix shows that these have zero UTC time offset (ie they are UTC times)

Javascript then uses T1, T2 and the current time (T) to define the pixel position where the current time indicator is to be drawn

File read in by
  <script type="Text/JavaScript" src="js/Session.Charts.js"></script>

The x pixel position of corresponding to the current time is calculated by

var nX = 1300;                //  width of both charts
var T = new Date();           //  current time
var ms = T.valueOf();         // .valueOf is number of milliseconds between
var ms1 = T1.valueOf();       //  1 Jan 1970 00:00:00 UTC and the respective date/time
var ms2 = T2.valueOf();

x = 10 + (ms-ms1)/(ms2-ms1) * (nX-2*10);    // where 10 is the left & right hand margin width

No changes are required to how Session.Charts.js is created or to how current time indicator is drawn on the session_current.htm page.

(Note: On nights when DST Changes, past issues where the current time line seems to be drawn in an incorrect position is not due to a failing in the above process but is due instead to a failing in how the the time scale & hour labelling is drawn on the underlying observing plan / observing results chart by AstroPlan).

Live Operations during DST Changes

In the past there have been operational issues during nights involving a DST change.

The most reliable and safest way of ensuring continuity of operations on nights where there is a DST change (with clocks going forward (March) or going backwards (October) is to force a Session Suspension during the times affected. 

The time intervals during which Session Suspension is to be forced (and other operations prevented such as AutoStart) are

•  Last Sunday of March, from: 00:50 UT to 01:10 UT
•  Last Sunday in October, from 00:50 UT to 02:10 UT

Critically the time interval in October covers the local time interval 01:00 to 02:00 which appears to repeat itself,  such that a local time like 01:30 is ambiguous in meaning.

At the start of a forced suspension the Job Queue will be suspended, the Observatory Dome will be closed & Telescope Tracking will be turned off . During the forced suspension the dome will not be allowed to open.  Other operations such as AutoStart will be prevented.

Whilst this reduces observing time, as opposed to a perfect continuously running (entirely UTC based) operation, it is the approach most likely to prevent problems.  The time lost is relatively small & affects only a couple of nights per year.

Defining forced session suspension windows

 

ForceSuspensionForDST

New Function   'ForceSuspensionForDST() as boolean'

The TimeZoneInfo.IsDaylightSavingTime (datetime) method indicates whether a specified date and time falls in the range of daylight saving time for the time zone of the current TimeZoneInfo object.

   TimeZoneInfo.Local.IsDaylightSavingTime(LT) indicates if time (LT) is in range of DST

Testing show this works, looking at the next two DST changes on 30 Oct 2022 and 26 Mar 2023

  Local Time         Is DST   UTC Time
 2022-10-29 23:45:00 True     2022-10-29 22:45:00
 2022-10-30 00:15:00 True     2022-10-29 23:15:00
 2022-10-30 00:45:00 True     2022-10-29 23:45:00
 2022-10-30 01:15:00 False    2022-10-30 01:15:00
 2022-10-30 01:45:00 False    2022-10-30 01:45:00
 2022-10-30 02:15:00 False    2022-10-30 02:15:00
 2022-10-30 02:45:00 False    2022-10-30 02:45:00
 2022-10-30 03:15:00 False    2022-10-30 03:15:00

 2023-03-25 23:45:00 False    2023-03-25 23:45:00
 2023-03-26 00:15:00 False    2023-03-26 00:15:00
 2023-03-26 00:45:00 False    2023-03-26 00:45:00
 2023-03-26 01:15:00 False    The supplied DateTime represents an invalid time
 2023-03-26 01:45:00 False    The supplied DateTime represents an invalid time
 2023-03-26 02:15:00 True     2023-03-26 01:15:00
 2023-03-26 02:45:00 True     2023-03-26 01:45:00
 2023-03-26 03:15:00 True     2023-03-26 02:15:00

Notes:

When the clocks go back in October  the local time 01:00 to 02:00 are all reported to be DST False and have UTC offset of 0 , even though the first (BST based) time interval  01:00:00 to 01:59:59 is actually DST = True with UTC offset of 1.  It is only after the clocks go back does the second (GMT based)  time interval 01:00:00 to 01:59:59 have DST = False and UTC offset of 0.   It is noticed that when taking LT 00:45 (=23:45 UT)  and then incrementing it by 30 minutes using LT = LT.AddMinutes(30),  the LT time becomes 01:15 (which is as expected) but the equivalent UT time jumps to 01:15 UT (ie UT time has jumped by 90 minutes).

It is unclear if .Net always give these results or it depends on the which side of a DST change the computer is currently running.  Would the results be the same when running the test code on 2022-11-01 (DST = False) as it is today 2022-08-31 (DST = True)

When clocks go forward in March the local times between 01:00:00 and 01:59:59 produce an exception "The supplied DateTime represents an invalid time. For example, when the clock is adjusted forward, any time in the period that is skipped is invalid".

 Local Time             Is DST   UTC Time
2022-10-29 23:30:00 BST  DST    2022-10-29 22:30:00
2022-10-29 23:45:00 BST  DST    2022-10-29 22:45:00
2022-10-30 00:00:00 BST  DST    2022-10-29 23:00:00
2022-10-30 00:15:00 BST  DST    2022-10-29 23:15:00
2022-10-30 00:30:00 BST  DST    2022-10-29 23:30:00
2022-10-30 00:45:00 BST  DST    2022-10-29 23:45:00
2022-10-30 01:00:00 BST  DST    2022-10-30 00:00:00
2022-10-30 01:15:00 BST  DST    2022-10-30 00:15:00
2022-10-30 01:30:00 BST  DST    2022-10-30 00:30:00
2022-10-30 01:45:00 BST  DST    2022-10-30 00:45:00
2022-10-30 01:00:00 GMT         2022-10-30 01:00:00
2022-10-30 01:15:00 GMT         2022-10-30 01:15:00
2022-10-30 01:30:00 GMT         2022-10-30 01:30:00
2022-10-30 01:45:00 GMT         2022-10-30 01:45:00
2022-10-30 02:00:00 GMT         2022-10-30 02:00:00
2022-10-30 02:15:00 GMT         2022-10-30 02:15:00
2022-10-30 02:30:00 GMT         2022-10-30 02:30:00
2022-10-30 02:45:00 GMT         2022-10-30 02:45:00
2022-10-30 03:00:00 GMT         2022-10-30 03:00:00

2023-03-25 23:30:00 GMT         2023-03-25 23:30:00
2023-03-25 23:45:00 GMT         2023-03-25 23:45:00
2023-03-26 00:00:00 GMT         2023-03-26 00:00:00
2023-03-26 00:15:00 GMT         2023-03-26 00:15:00
2023-03-26 00:30:00 GMT         2023-03-26 00:30:00
2023-03-26 00:45:00 GMT         2023-03-26 00:45:00
2023-03-26 02:00:00 BST  DST    2023-03-26 01:00:00
2023-03-26 02:15:00 BST  DST    2023-03-26 01:15:00
2023-03-26 02:30:00 BST  DST    2023-03-26 01:30:00
2023-03-26 02:45:00 BST  DST    2023-03-26 01:45:00
2023-03-26 03:00:00 BST  DST    2023-03-26 02:00:00


TheSky6
For the one hour period after clocks go back at end of daylight saving time, it isn't possible to set TheSky6 to the equivalent UT time.   For the time 01:30 LT / 01:30 UT on the last Sunday in October (UK) it isn't possible to set TheSky6 to show virtual sky at 01:30 UT. Trying to set TheSky6 time to 01:30 using TheSky6's interface, one gets a virtual sky that is for 01:30 BST / 00:30 UT.   If one try to set TheSky6 to time of an image taken at 01:30 UT one gets a virtual sky for 02:30 GMT/ 02:30 UT.  This seems to be an inherent weakness in the TheSky6 (not sure what TheSkyX does ?). 

If TheSky6 Clock is at 02:01 LT (GMT) / 02:01 UT on the last Sunday in October (UK), and time is stepped backwards by 1 minute, the TheSky6 clock goes to 02:00 LT / 01:00 UT.  Universal time has stepped back a full hour !  LST jumps similiarly by one hour from 04:26:28 to 03:25:18 (2022). This is a bug in TheSky6.

Confirmation of the bug was confirmed later during a series of tests using TheSky6's ConvertCalenderToJD and SetWhenWhere.

For a one one period after the clocks go onto daylight savings time, the Local Time stated by TheSky6 is incorrect (in stays on GMT for 1 hour longer that it should :   If TheSky6 Clock is at 00:59 LT (GMT) / 00:59 UT on the last Sunday in March (UJ) and time is stepped forwards by 1 minute, the clock goes to 01:00 LT / 01:00 UT. (It should go to 02:00 LT (BST) / 01:00 UT ! ). Step forward a further minute and the clock goes to 01:01 LT / 01:01 UT. There should actually be any local times between 01:00 and 01:59 on this date, as the official clocks in UK steps forward by hour at 01:00.   Once TheSky6 clock reaches 01:59 LT / 01:59 LT, then stepping forward by 1 minute sees the TheSky6 clock change to 03:00 LT (BST) / 02:00 UT.   So finally the 'Clock' steps forward by 1 hour, but this occurred at 02:00 (LT) i.e. one hour later than it should have.  This is a bug in TheSky6.

It is unclear what TheSky6 does when it is running on Computer Time as the DST Change happens.

Last Sunday in March (Clock Moves forward by 1 hour at 01:00)

If one what's to

Last Sunday in October  (Clock Moves back by 1 hour at 02:00)
On last Sunday in October we have a clear unique issue for Local Times between 01:00:00 to 01:59:59.  Unless it is explicity defined,  a time during this period  such as 01:30:00 could be referring to 01:30:00 BST / 00:30:00 UT or it could be referring to 01:30:00 GMT / 01:30:00 UT.  We don't know.

S930 (2021-10-30)  - including DST Change on 2021-10-31
Examples in session S930 target 17/37 (GCVS TV Cas) began at 2021-10-31 00:55 (BST) and took images between 00:56 and 01:04 (BST)
Report File and FITS Headers correctly reports these images as having UT times between 23:56 and 00:04 UT.   Targets 18/37 to 21/38 similarly had no issues. 

Target 22/38 (GCVS DY Per) began at 2021-10-31 01:56 (BST) and took images between 01:57 and 01:59 (BST)
When clock moved back 1 hour at 02:00,  AstroMain ran into a DST related issue where in instead of pausing the Job Queue Thread for 5s it began pausing it for 3587s (around 1 hour !) .  It was until 45 minutes later that it was noticed that Job Queue had frozen, and the program was killed and restarted.

Target 22/37 (GCVS RR Tau) began at 02:07 (GMT) and took images between 02:09 and 02:21 (GMT).   Report File and FITS headers for these fille correctly record images times of between 02:09 and 02:21 UT.  

Local Times produced by VB.Net's DateTime.Now() are fully aware of whether times have a +0:00 UT offset (GMT) or a +1:00 UT offset (BST), so display of clock time (HH:mm:ss) are always correct and DateTime.ToUniversalTime works ok.  CCDSoft has no problem and ensure that FITS files are timestamped with the correct UT time.

AstroPlan
Problem comes when we try to plot an Observing Plan or Observing Result chart. 
When we try to plot GCVS DY Per's Start Time (2021-10-31 01:56:00), the time is first imported using
   lt_time = DateTime.Parse("2021-10-31 01:56:00")
and then converted to UT Time using  Data  using (lt_time) is converted to UT using
   ut_time = lt_time.ToUniversalTime.
This result in the observation plotting at 01:56 UT, instead of its correct position at 00:56 UT.

Given the ambiguity between 01:00:00 and 01:59:59.  DateTime.Parse ( date/time formatted string ) seem to use the base offset for UK Time Zone (+0:00)
in this situation.  In order to import DY Per's Start Time correctly, the time would have to be imported using
   lt_time = DateTime.Parse("2021-10-31 01:56:00 +1:00")

Observing Result chart similarly has a problem plotting key Session Events correctly. Event "Program Hung" at 01:59 (BST) is plotted at 01:59 UT (instead of at 00:59 UT), and appears after the "User Intervention" Event  at 01:45 (GMT) which is plotted at 01:45 UT.

Recommendation
AstroPlan database and AstroPlan handling should be modified to store UT times and not Local Times, since conversion from UT to Local is unique, whereas conversion from Local to UT is ambiguous without a UT offset.   Forms should show both Local and where needed.  AstroMain should be modified to SaveSessionEvents, Save Observation Result with UT time.

For converting existing database values the assumption should be that local times between 01:00:00 and 01:59:59 on the 4th Sunday in October are BST times,  as this are most likely a continuation of a sequence of events/observations from prior to 01:00. Data for relevent dates (such as from S930) should be checked and manually adjusted as appropriate based on temporal relationships that are evident from Log and Report Files.

Schedule Builder should create a schedule based on UT times, rather than LT times.  This will avoid creating plan observations with Local Times between 01:00 and 02:00 on the last Sunday in March, and allow observations to be planned for both 01:00 to 01:59 BST and 01:00 to 01:59 GMT in the same plan.

Local Times currently written to AstroMains' Report File  as    "HH:mm     (Local)" ,  should be written as HH:mm   (Local, BST) or  (Local, GMT)

Saving UT time to Database
Following line to be used for building the command string to store a UT date/time in database.   Datetime to be formatted to ISO standard.

    sb.Append(" " + "DateTime,  ")
  sb.Append ...
  sb.Append(" " + DQ(UT_Time.ToString("yyyy-MM-ddTHH:mm:ssZ")) + ",")

Read UT time from Database
Following outline line to be used for reading UT time from database and generating the local time equivalent.

    Dim UT_Time as date
   Dim LT_Time as date

   sb.Append ("Select DateTime from table"
   sb.Append.... etc
 
   While (objReader.Read())
       UT_Time = DateTime.Parse(objReader("DateTime").ToUniversalTime
       LT_Time = UT_Time.ToLocalTime
   End While

write

CheckForDstChangeTonight()
After an observing session is created or reopened the following new routine is called which then uses function GetNightClockChange() and subroutine SetForcedSuspensionTimes() to determine whethera  DST Change will take place during a particular night session, and if so sets up UT time interval that the session will be forced to be suspended.   CheckForDstChangeTonight is called by AssignObservatorySession() directly after Session.NightDate is set.

Sub CheckForDstChangeTonight()
'===========================

  ' Ensure Night Date is set
  ' ------------------------
  If Session.NightDate = "" Then
    Session.NightDate = GetNightDateNow()
  End If

  ' Get Clock Change Tonight (0 = no chnage, -1 clock goes back, 1 clock goes forward)
  ' ------------------------
  Session.DstChange = GetNightClockChange(Session.NightDate)

  ' Set Forced SuspensionTimes (UT time interval when running session will be forced to suspend
  ' --------------------------
  SetForcedSuspensionTimes()

End Sub

GetNightClockChange()
For a given night date we can establish if a DST Change will take place during a particular night session, using the following new function which returns +1 if the clock goes forward , -1 if the clock goes back , or 0 if there is no change in the clock.

 Function GetNightClockChange(NightDate As String) As Integer
'===========================
' Note: Night Date is passed as string in format "yyyy-MM-dd"

  Dim T0, T1, T2 As Date
  Dim b1, b2 As Boolean

  T0 = DateTime.Parse(NightDate)

  T1 = T0.AddHours(21) ' 21:00 on NightDate
  b1 = TimeZoneInfo.Local.IsDaylightSavingTime(T1)

  T2 = T1.AddHours(12) ' 09:00 on day after NightDate
  b2 = TimeZoneInfo.Local.IsDaylightSavingTime(T2)

  If b1 = True And b2 = False Then         
     return = -1       ' clock goes back during night
  ElseIf b1 = False And b2 = True Then
     return = 1        ' clock goes forward during night
  Else
     return = 0        ' no change in clock
  End If

End Function

SetForcedSuspensionTimes()
Based on whether the clock goes forward or goes back for a particular night session the following new subroutine to set a time interval during which an active session will be forced to be suspended. 

 Sub SetForcedSuspensionTimes()
'========================
  Dim D2 As Date
  Dim S As String

  With Session

    ' Get Date corresponding to when clock actually change, rather than the Night Date (which is for previous evenining)
    ' --------------------------------------------------------------------------------
    D2 = DateTime.Parse(.NightDate).AddDays(1) 

    ' Set Forced Suspension Times
    ' ---------------------------
    If .DstChange = -1 Then   
 
       ' Set Start/End Times for Forced Session Suspension, for when Clock goes back (October)
       ' -------------------------------------------------
      .ForceSuspensionStartTimeUT = DateTime.Parse(D2.ToString("yyyy-MM-dd") + " 00:50:00Z").ToUniversalTime()
      .ForceSuspensionEndTimeUT = DateTime.Parse(D2.ToString("yyyy-MM-dd") + " 02:10:00Z").ToUniversalTime()
           .DstChangeTimeUT = DateTime.Parse(D2.ToString("yyyy-MM-dd") + " 02:00:00Z").ToUniversalTime()
 
    ElseIf .DstChange = 1 Then 
 
       ' Set Start/End Times for Forced Session Suspension, for when Clock goes forward (March)
       ' -------------------------------------------------
       .ForceSuspensionStartTimeUT = DateTime.Parse(D2.ToString("yyyy-MM-dd") + " 00:50:00Z").ToUniversalTime()
       .ForceSuspensionEndTimeUT = DateTime.Parse(D2.ToString("yyyy-MM-dd") + " 01:10:00Z").ToUniversalTime()
       .DstChangeTimeUT = DateTime.Parse(D2.ToString("yyyy-MM-dd") + " 01:00:00Z").ToUniversalTime()
 
    Else
 
       ' No Change in Clock
       .ForceSuspensionStartTimeUT = vcNullDate
       .ForceSuspensionEndTimeUT = vcNullDate
       .DstChangeTimeUT = vcNullDate
    End If
  End With

GetClockChangeTime()
New function (in AstroPlan) that return the UT time that clock change occurs.

Function GetClockChangeTime(NightDate As String) As Date ' added 2022-09-03 (CI S1034)
'==========================
  Dim D2 As Date
  Dim S As String
  Dim DstChange As Integer

  DstChange = GetNightClockChange(NightDate)

  If DstChange = -1 Or DstChange = 1 Then

    ' Get Date corresponding to when clock actually changes, rather than the Night Date (which is for previous evenining)
    ' -----------------------------------------------------
    D2 = DateTime.Parse(NightDate).AddDays(1)

    ' Return UT time of Clock Change
    ' ------------------------------
    If DstChange = -1
       Return DateTime.Parse(D2.ToString("yyyy-MM-dd") + " 02:00:00Z").ToUniversalTime()
    Else ' DSTChange = 1
       Return DateTime.Parse(D2.ToString("yyyy-MM-dd") + " 01:00:00Z").ToUniversalTime()
    Endif
  Else
    Return vcNullDate
  End If

End Function

DstIsChanging()
New function ForceSuspensionForDstChange() is used to determine if a DST Change is occuring and that the Current Session needs to be placed into (or kept within) a Suspended State.

ForceSessionSuspend

Function DstIsChanging() As Boolean
' ==================================
   Dim UtcNow As Date

   ' Immediately Return False if there is no DST Change for the Current Night Session
   ' --------------------------------------------------------------------------------
   If Session.DstChange = 0 Then
      Return False
   End If

  ' Get Current Utc Time
  ' --------------------
  UtcNow = DateTime.UtcNow

  ' Determine if we're currently within the Required Suspension Time Interval (previously set)
  ' -------------------------------------------------------------------------------------
  If UtcNow >= Session.ForceSuspensionStartTimeUT Or UtcNow <= Session.ForceSuspensionEndTimeUT Then
    Return True
  Else
    Return False
  End If

End Function

MustClose()
Function is updated to return False (reason = "DST Change") when DstIsChanging() = True
This ensures that Observatory Dome must close (if it is open), can't be opened (if it closed) and that the Session can't be resumed until the period of the DST Change (during which Forced Suspension condition operates) has passed.

Enum FailureState
Enum extended to include  'DstChange = 28'

WriteReasonToSuspend()
Extended to return "DST Change" for FailureState.DstChange

Corresponding change also needed to AstroPlan.

Obs.Manager()
Observatory Manager main loop modified to report DST Change Alerts & Clock Change events.  Since MustClose() has been modified to return True when DstIsChanging = True existing HardSuspend handling will operate to suspend job queue, close observatory dome and put the session into Suspended State.

Only other addition if that is Suspended State, a check if made to turn off Telescope tracking if DstIsChanging()
  

AstroPlan - Observing Plan and Observing Results Chart
The Time Interval Width on the Observing Plan, Altitude Plan and Observing Result Charts need to adjusted on nights when the DST Changes.  

•  On the night of DST Change in March when clocks goes forward by 1 hour the hour range on the chart needs to be 1 hour less than normal.  
   
• On the night of DST Change in October when clocks goes backward by 1 hour  the hour range on the chart needs to be 1 hour more than normal.  

The hour annotation used on these charts should reflect the change in local time on nights when the DST Changes. 

• On the night of DST Change in March when clocks goes forward by 1 hour the HH labels will take the sequence ..23  00  01/02  03  04..
   
•  On the night of DST Change in October when clocks goes backward by 1 hour  the HH labels will take the sequence ..23  00  01  02/01  02  03  04..

If possible the respective parts of the chart hour axis should be labelled GMT or BST as appropriate.

AstroPlan - Night
 Night object extended to include DstChange as integer to record whether clocks go forward (+1), go back (-1) or don't change (0)

AstroPlan - GetNightClockChange()
 GetNightClockChange() routine copied  from AstroMain

Environmental Charts
Various environmental and information charts should also have Time Interval Width and HH labelling adjusted on nights when the DST Changes.

Actions

AstroMain Operations. Make Changes to AstroMain to Suspend Session around the time that Clock is Changing  (DST Changes).
AstroMain Graphs. Make Change to AstroMain graphs to handle changes in clock (going forward or back).

BuildSchedule (Build Observing Plan)

SetupTImeProfile() routine builds a time profile with a ProfileStartTime that is taken as the Night.Sunset datetime rounded down to a whole hour.   This is a date time of unspecified kind
but is used as a Local Time.  nProfile items is based on difference between Sunrise time (as a Unspecified/Local Time) divided by the Profile Increment (10 minutes).

Each record in the ProfileTime array is filled with a 'Time' (based on ProfileStartTime, incrementing regularly by 10 minutes),  a 'JD' value (calculated using TheSky6.Utils.ConvertCalenderToJulianDate()  with  yyyy, MM, dd, HH, mm & ss parameters based on 'Time'), a LST value (calculated using internal function 'calcLST' which gives LST based on JD value.

The description of TheSky6's  ConvertCalenderToJulianDate method say that converts a Calender Date (year, month, day, hour, minute and second) to a Julian date, but doesn't say if it should be a UT date/time or it takes local date/time (and converts as neccessary to UT itself)

Entering UT date/time 2022-09-07 23:14:11 to AAVSO's JD Calculator ( https://www.aavso.org/jd-calculator ) returns JD  2459830.46818, but passing 2022-09-07 23:14:11 values to  TheSky6's  ConvertCalenderToJulianDate returns JD 2459830.4265162 which is clearly different. The difference (0.0416638) corresponds to 1 hour.  However if the equivalent local time (2022-09-08 00:14:11) is passed to TheSky6's  ConvertCalenderToJulianDate() function it returns JD 2459830.46818287 which is the same as that given by AAVSO's JD calculator.   TheSky6's  ConvertCalenderToJulianDate() function requires a date/time to be given in local time.

It has been shown that TheSky has a problem with Time settings during the time that clocks go back at end of daylight savings

1  UT 2021-10-30 23:00:00  LT 2021-10-31 00:00:00 JD 2459518.45833333
2  UT 2021-10-30 23:15:00  LT 2021-10-31 00:15:00 JD 2459518.46875
3  UT 2021-10-30 23:30:00  LT 2021-10-31 00:30:00 JD 2459518.47916667
4  UT 2021-10-30 23:45:00  LT 2021-10-31 00:45:00 JD 2459518.48958333
5  UT 2021-10-31 00:00:00  LT 2021-10-31 01:00:00 JD 2459518.5
6  UT 2021-10-31 00:15:00  LT 2021-10-31 01:15:00 JD 2459518.51041667
7  UT 2021-10-31 00:30:00  LT 2021-10-31 01:30:00 JD 2459518.52083333 (AAVSO JD 2459518.52083) - match
8  UT 2021-10-31 00:45:00  LT 2021-10-31 01:45:00 JD 2459518.53125    (AAVSO JD 2459518.53125) - match
9  UT 2021-10-31 01:00:00  LT 2021-10-31 01:00:00 JD 2459518.5        (AASOS JD 2459518.54167 - different
10 UT 2021-10-31 01:15:00  LT 2021-10-31 01:15:00 JD 2459518.51041667
11 UT 2021-10-31 01:30:00  LT 2021-10-31 01:30:00 JD 2459518.52083333 (AAVSO JD 2459518.56250) - different
12 UT 2021-10-31 01:45:00  LT 2021-10-31 01:45:00 JD 2459518.53125
13 UT 2021-10-31 02:00:00  LT 2021-10-31 02:00:00 JD 2459518.54166667 (AAVSO JD 2459518.58333) - different
14 UT 2021-10-31 02:15:00  LT 2021-10-31 02:15:00 JD 2459518.59375    (AAVSO JD 2459518.59375) - match
15 UT 2021-10-31 02:30:00  LT 2021-10-31 02:30:00 JD 2459518.60416667
16 UT 2021-10-31 02:45:00  LT 2021-10-31 02:45:00 JD 2459518.61458333 (AAVSO JD 2459518.61458) - match

So passing 2021-10-31 01:30:00 to TheSky6's ConvertCalenderToJulianDate gives a JD that indicates that TheSky6 has assumed the 01:30:00 to be a BST (DST) datetime. It doesn't seem possible to get the JD date that is equivalent to 01:30:00 GMT.

Using TheSky6's RASCOMTheSky.SetWhereWhen to set TheSky to JD 2459518.56250 (the AAVSO JD for 2021-10-31 01:30:00 UT,  2021-10-31 01:30:00 GMT) causes TheSky6 to have the Time 02:30 Local, 02:30 UT and a JD 2459518.6042 which whilst corresponding correctly for 02:30 UT time is clearly different to the JD date that was requested (2459518.56250). This confirms the bug noted earlier.

So between 01:00 and 02:00 UT on night that clocks go backnTheSky6 cannot be relied on to give correct information such as Az/Alt of a target,  or the correct RA/Dec coordinates of a fast moving non-sidereal target.  If needed it is probably possible to get the values from one hour before and the values from one hour after the required time point and then take the midpoint average as a good approximation.

GetNightTimes() - changed Night record dates (like .sunrise, dusk6 etc)  from Local to UT format
SetupTimeProfile() - updated to create profile based on UT times
CompileSunMoonData()  - updated to get JD direct from ProfileTime where JD's have already been calculated

ValidateMoonConstraints() - updated to get Start/EndStep based on UT Times.
ValidateSunConstraints() - updated to get Start/EndStep based on UT Times.
CreatePlan() - updated to get StartTime based on UT Times
Plan.AddTarget - modified in interim to convert Target

Session Events Work
-  Session Events Form
   - data retrieval
   - data editing (times) new row
   - data saving
- Code for Table conversion

- Modifications to StoreSessionEvent() routine in AstroMain
-  AutoStart Events (including in Live Session Events)

Submit ToO
When a Target Of Opportunity (ToO) is submitted from AstroPlan a Flag file (ToO_File.dat) is written that includes ToO Target Name//TargetID, ToO Priority along with a StartTime, based on Now() and an Expire Time (based on Now().AddMinutes(window minutes). These dates are written in the format "yyyy-MM-dd HH:mm:ss".  The ToO Priority is the value that is principally used by AstroMain for inserting the ToO into the active job queue, but the date fields are also used for detailed control.  Normally the date values are read in and treated as local time according to the DST state at the time. 
When clocks go back and there is potential ambiguity over a datetime of unspecfied kind, there is a risk that a ToO isn't executed at the time intended or the ToO isn't executed, because it time window was deemed to have passed.  To prevent ambiguity it is proposed that ToO requests are written to the Flag file with UT date/times with format "yyyy-MM-ddTHH:mm:ssZ".

This involves updates to AstroPlan's SubmitToO() routine,  AstroVOE's SubmitToO() routine (similar), and AstroMain's FetchToO(), CheckForPendingToO() & HandleToO() routines.

Session Events Migration (2022-09-04)
1) Make Database Backup  ('Targets Database (2022-09-04 2331)' )
2) Temporarly disable writing to sessionevent table from SaveSessionEvents() routine
3) Finalise Code changes in ConvertSessionEventsToUT and test
4) Run ConvertSessionEventsToUT, and archive the Report File (as AstroPlan.ConvertSessionEventsToUT.2022-09-04.htm)
5) Protect  accidental future corruption of sessiontable by hiding ConvertSessionEventsToUT() behind  'Exit Sub' code lines, thus preventing its re-run.
6) Finalise Code changes in LoadSessionEvents() routine and test
7) Finalise Code changes in SaveSessionEvents() routine and test (short of making actual database changes)
8) Finalise Code changes in SaveHtmReport &  SaveHtmReport_Short and test
9) Finalise Code changes in InsertSessionEvent() routine
10) Re-enable writing to sessionevent table from SaveSessionEvents() routine
11) Finalise Code changes to SessionEvents.LoadResultEvents() & SessionAlerts.LoadResultEvents()
12) Finalise Code changes to PlotChart
13) Make new Database Backup  ( 'Targets Database - Copy at 2022-09-05)' )
14) Finalise Code changes to AstroMain, with changes to StoreSessionEvent(), ObservingDB.InsertSessionEvent(), ObservatoryManager.WriteEventFile() and test.
15) Ensure new program versions ( AstroMain 3.54.2 and AstroPlan 1.32.1) are copied to Local
16) Ensure that database and two new program versions are copied to Observatory Computer at same time.
17) Next day identify also need to change data GridView_CellValueChanged()

Session Events Migration (2022-09-05)
1) Make Database Backup  ('Targets Database - Copy at 2022-09-05 v2' )
2) Temporarly disable writing to sessionalert table from SaveSessionAlerts() routine
3) Finalise Code changes in ConvertSessionAlertsToUT and test
4) Run ConvertSessionEventsToUT, and archive the Report File (as AstroPlan.ConvertSessionAlertsToUT.2022-09-05.htm)
5) Protect  accidental future corruption of sessiontable by hiding ConvertSessionAlertsToUT() behind  'Exit Sub' code lines, thus preventing its re-run.
6) Finalise Code changes in LoadSessionAlerts() routine and test
7) Finalise Code changes in GridView_CellValueChanged() routine and test
8) Finalise Code changes in SaveSessionAlerts() routine and test (short of making actual database changes)
9) Finalise Code changes in SaveHtmReport &  SaveHtmReport_Short and test
10) Finalise Code changes in InsertSessionAlerts() routine
11) Re-enable writing to sessionalert table from SaveSessionEvents() routine
12) Finalise Code changes to SessionEvents.LoadResultEvents() & SessionAlerts.LoadResultEvents()
13) Finalise Code changes to PlotChart
14) Make new Database Backup  ( 'Targets Database - Copy at 2022-09-05)' )
15) Finalise Code changes to AstroMain, with changes to
      StoreSessionAlert2(), ObservingDB.InsertSessionAlert(), ObservatoryManager.WriteAlertFile() and test.
16) Ensure new program versions (AstroMain 3.54.2 and AstroPlan 1.32.1) are copied to Local
17) Ensure that database and two new program versions are copied to Observatory Computer at the same time.

Session Observations Migration (2022-09-06)
1) Make Database Backup  ('Targets Database - Copy at 2022-09-06' )
2) Temporarly disable writing to observation table from SaveObservations() routine
3) Finalise Code changes in ConvertSessionObservationsToUT and test
4) Run ConvertSessionObservationsToUT, and archive the Report File (as AstroPlan.ConvertSessionObservationsToUT.2022-09-06.htm)
5) Protect  accidental future corruption of sessiontable by hiding ConvertSessionObservationsToUT() behind  'Exit Sub' code lines, thus preventing its re-run.
6) Finalise Code changes in LoadObservations() routine and test
7) Finalise Code changes in SaveObservations() routine and test
8) Finalise Code changes in InsertObservation() routine
9) Re-enable writing to observation table from SaveObservations() routine
10) Finalise Code changes to PlotChart and test
11) Make new Database Backup  ( 'Targets Database - Copy at 2022-09-06 v2a' )
12) Correct for actual DST for 3 observations from S930 (2021-10-30), Sequence Numbers 17 to 19
13) Make new Database Backup  ( 'Targets Database - Copy at 2022-09-06 v2b' )
14) Finalise Code changes to AstroMain, with changes to ObservingDB.InsertObservation()
15) Ensure new program versions (AstroMain 3.54.3 and AstroPlan 1.32.2) are copied to Local
16) Ensure that database and two new program versions are copied to the Observatory Computer at the same time.

Plan Observations Migration (2022-09-08)
1) Make Database Backup  ('Targets Database - Copy at 2022-09-08' )
2) N/A Temporarly disable writing to plan_observation table from SaveObservations() routine
3) Finalise Code changes in ConvertPlanObservationsToUT and test
4) Run ConvertPlanObservationsToUT, and archive the Report File (as AstroPlan.ConvertPlanObservationsToUT.2022-09-08.htm)
5) Protect  accidental future corruption of sessiontable by hiding ConvertPlanObservationsToUT() behind  'Exit Sub' code lines, thus preventing its re-run.
6) Finalise Code changes in LoadPlanObservations() routine and test
7) Finalise Code changes in SavePlanObservations() routine and test
8) Finalise Code changes in InsertPlanObservation() routine
9) Re-enable writing to plan_observation table from SaveObservations() routine
10) Finalise Code changes to PlotChart and AltPlotChart and test
11) Make new Database Backup  ( 'Targets Database - Copy at 2022-09-08 v2a' )
12) Correct for actual DST for 3 observations from S930 (2021-10-30), Sequence Numbers 18 to 21 (Report File archived as AstroPlan.ConvertPlanObservationsFixForS930.2022-09-08.htm)
13) Make new Database Backup  ( 'Targets Database - Copy at 2022-09-08 v2b' )
14) Finalise Code changes to AstroMain, with changes to RetrieveTarget
15) Ensure new program versions (AstroPlan 1.32.3 and AstroMain 3.54.4) are copied to Local
16) Ensure that database and two new program versions are copied to the Observatory Computer at the same time.

Submit ToO Migration (2022-09-09)
1) Finalise code changes to AstroPlan's SubmitToO() & GetOptimalStartTime() routines
2) FInalise code changes to AstroVOE's SubmitToO() routine
3) FInalise code changes to AstroMain's FetchToO(), CheckForPendingToO() & HandleToO() routines.
4) Ensure that  new program versions (AstroPlan 1.32.4, AstroVOE 1.11, and AstroMain 3.54.5) are copied to the Observatory Computer at the same time.

Implementation Results (illustrated using Session S930 (2021-09-30) which saw clock go back by 1 hour during the session)

Observing Plan - Original vs New Plot

Altitude Plan - Original vs New Plot

 

Observing Result - Original & New Plots (S930)

 

Start/End Times, Graphs StartTimes, SessionData (2022-09-24)

Session.StartTime  - Done
Session.EndTime  - Done
LastShutterCloseTime  - Done
MasterGraphStartTime
CcdTempChart.StartTime
FocusTempChart.StartTime
ZenithFwhmChart.StartTime
BestFocusChart.StartTime
Cam2TempChart.StartTime
SkyQualityChart.StartTime
Phd2.LastIncompleteReadTime

GetGraphStartTime
CcdTempChart.StartChart
CcdTempChart.AddData
CcdTempChart.ExtendGraph
CcdTempChart.DrawLegend
CcdTempChart.DrawAxesLabels

CcdTempChart     - Done
FocusTempChart - Done
Cam2TempChart - Done
SkyQualityChart   - Done
ZenithFwhmChart - Done
BestFocusChart   - Done
MasterGraphStartTime - Done

Phd2.LastIncompleteReadTime

Changes implemented in AstroMain 3.54.10 (2022-09-24).

 

AstroWeather Graphs (2022-09-26)

Cloud Sensor
Record date/times produced by Aurora Cloud Sensor III and stored in 'CloudSensor_Data.csv) are UT based.

AstroWeather's ParseCSRecord() routine compiles a .DateTime string from 'Date' + " " + 'Time' and converts it to a date variable  .DateX = DateTime.Parse(.DateTime).   This probably means that DateX is of unspecified kind.

For plotting data PlotGraphs() routine converts Cs record times to local time using DataTime = CsData(i).DateX.ToLocalTime()

[ when a date is of Unspecifed kind, then using .ToLocalTime will assume that the original date was a universal time,  whilst using .ToUniversalTime will assume that the original date was a local time and convert accordingly ]

Star Count numbers produced by AstroAllSky and stored in AllSky (stars).dat are

Graphs are controlled by 'PlotTime'    For each graph PlotStartTime is derived from PlotTime with the code line
  .PlotStartTime = PlotTime.AddHours(- .PlotHours)

where PlotTime = RefTime,  and RefTime = Now()

Record date/times produced by Virtual Weather Station (VWS) are a local time in the format yyyyMMddHHmm  (e.g. 202209261645 for 2022-09-26 16:45 BST)

AstroAllSky /  Stars
AllSky Stars Record date/times produced by AstroAllSky (3.16.3) are a local time in the format  yyyy-MM-dd, HH:mm:ss  (e.g. 2022-09-26, 06:52:27)
Date/ Times are repeated for one hour period when clocks go back. During this 1 hour period the AllSkyStarCount number continues correctly, but the AllSkyDisplayStars numbers drops significantly.   For DST Change at 2021-10-31 02:00 the AllSkyStarCount continues at a level of 21-22 but AllSkyDisplayStars drops from 54-56 to 2-3.  This has been noticed before in the NightSummary6 plots.

During this 1 hour MeasureDisplayStar(ID) uses a TheSky6 method to get AzAlt of a DisplayStar ( AzAlt = Utils.ConvertRADecToAzAlt(.Ra2000, .Dec2000) ).  But this gives and incorrect coordinates around the time of DST change due to inability to handle times correctly.   It is proposed to replace this call with routine to AstroRoutines.ConvertRaDecToAzAlt
Other Utils functions (e.g. Utils.ComputeJulianDate) may also be incorrect during this one hour period and again AstroRoutine equivalent should be used.

ObsEnvData.dat
AstroMain ObsEnvDate record date/times are a local time in the format  yyyy-MM-dd HH:mm:ss

Changes to AstroWeather Charts to make them DST Friendly implemented in AstroWeather 1.18 (2022-09-26).

AstroMain / ObsEnv Changes (2022-09-27)

ObsEnv Records are currently created with timestamps that are in local time in the format  yyyy-MM-dd HH:mm:ss.  This precludes the correct storage of ObsEnv data for the one hour period that clocks go back at end of daylight savings.  This prevents this data from being plotted on AstroWeather Charts for night when DST changes.

Future ObsEnv Records will have timestamps that are in UT time based in the format 'yyyy-MM-ddTHH:mm:ssZ'.

Involves changes to ObsEnv.GetObsEnvData(), ObsEnv.WriteDataRecord(), BuildRecord,  Environment.TimeSinceLastUpdate(),  Environment.TimeOfLastUpdate()  routines
Also changes to SecondsSince, MinutesSince, HoursSince and DaysSince to ensure time span is calculated with same the DateTimeKind as the supplied timepoint.

AstroWeather / ObsEnv Changes (2022-09-27)
Query why does Graphs.GetData  call  Old_ParseObsEnvRecord() instead of ParseObsEnvRecord() (Info:  the latter has no references)

Changed Old_ParseObsEnvRecord()  ( and ParseObsEnvRecord() ) to converted imported ObsEnv timestamp to a UT time.

AstroMain / Scorecard Changes  (2022-09-27)
Synoposis.Time &  Synoposis.LastScorecardTime changed to UTC time.

Observatory Software Installs (2022-09-27)
- Installed AstroAllSky 3.17
- Installed AstroWeather 1.18
- Installed AstroMain 3.55
- Installed AstroGuard 1.9
- Installed AstroVOE 1.12