Program Scheduler and DST Changes Bug

[inl_inc]

Came across this bug back in November when the clock was turned back by 1 hour.

I have the program scheduler set up to run a new program/script every hour on top of the hour. The new program is set to soft start with 5 min lead time. As I recall the final result was that one of my scrips ended up running for an extra hour by looping the last script line.

I think the following happened:
Sunday, November 3, 2013 at 1:00:00 AM - 1AM program/script started
Sunday, November 3, 2013 at 1:55:00 AM - 2AM program/script started
Sunday, November 3, 2013 at 2:00:00 AM clocks were turned backward 1 hour to 1:00:00 AM
As a result 2AM script ended up running for 2 hours instead of 1

Berndt - will you be able to patch the scheduler to account for daylight savings time changes in fall/spring?

[radio42]

The scheduler already accounts for daylight saving. And your observed behavior is correct and works as expected.
In autumn the clock is turned back one hour. As such the same hour is occurring twice and the resp. program runs one additional hour.
In spring the opposite is happening and the clock is advanced by one hour which means the resp. hour will be skipped.
All this is correct to my mind!

[inl_inc]

the problem with running the existing (i.e 1AM script) for an extra hour is that it ends up repeating the looped script line ... so for that hour the programming does not follow the clockwheel

what i would have liked to happen is to have the 1AM program/script be re-triggered at 2AM (which really became 1AM) ... this way my 1 hour program would run as expected (instead of having the script loop the last track selection for 15 times) ...

i hope that this would be possible to implement in the new year ... i would imagine that when the clocks go forward 1 hour in the spring this would not be a problem - as the scheduler should simply skip 1 hour program instead of extending the existing 1 hour program into two hours ...

[inl_inc]

the problem with running the existing (i.e 1AM script) for an extra hour is that it ends up repeating the looped script line ... so for that hour the programming does not follow the clockwheel

what i would have liked to happen is to have the 1AM program/script be re-triggered at 2AM (which really became 1AM) ... this way my 1 hour program would run as expected (instead of having the script loop the last track selection for 15 times) ...

i hope that this would be possible to implement in the new year ... i would imagine that when the clocks go forward 1 hour in the spring this would not be a problem - as the scheduler should simply skip 1 hour program instead of extending the existing 1 hour program into two hours ...

here's an illustration of what happened using a hypothetical script/music library ... let's assume that each music track in the library is approximately 15 minutes long and the script does the following:
0:00:00 --> select track from TOP OF THE HOUR ID library
0:00:05 --> select track from 60s_library
0:15:00 --> select track from SWEEPERS library
0:15:05 --> select track from 70s library
0:30:00 --> select track from SWEEPERS library
0:30:05 --> select track from 80's library
0:45:00 --> select track from SWEEPERS library
0:45:05 --> select track from 90's library *** this line is looped in case the full hour is not filled

so the hourly clockwheel is pretty straight forward --> ID, song, sweeper, song, etc ...

what ended up happening for the additional hour that the scrip was allowed to run is that my clockwheel played 4 90's tracks instead of following the pattern specified above ... hopefully this provides some needed colour to what i described in my first post ...

[radio42]

I am sorry to say, but I guess this will not happen.
When daylight saving will happen you would have to deal with this upfront, e.g. plan your extra hour.
This is absolutely logical and normal.

Just repeating/triggering the same program twice would not work for a lot of other users (e.g. for all users who manually pre-scheduled the program or did extra voice-tracking or all users which doesn't schedule at the exact daylight saving boundaries).
So I guess your case is the rather special case and you can easily schedule an exception - a dedicated program running 1 extra hour...simple.

[inl_inc]

Berndt - thanks for your quick responses.

I guess because i wasn't expecting this behaviour it created a problem for me where one additional hour ended up being scheduled with the same type of a track. If i'm the only one who thinks this is a problem - then i can live with the work around by creating a custom script for when the clocks go back 1 hour. Can you please take a look at the hypothetical scenario below to make sure that it will work as i expect:

standard script is created to fill 1 hour (assuming 15 minute track length) with the last track being looped in case 1 hour is not filled ... all programs are started with a soft start and are given a 10 minute margin ... i.e. start at 5 min prior to top of the hour and are allowed to run 5 min past the top of the hour (we'll use the same script example that I gave in my previous post) ... second assumption is that the DST time changes happens 1 second prior to 2AM ...

CASE 1: November clocks turned back
12:00AM program (started at 11:55PM) --> uses standard 1 hour script
1:00AM program (started at 12:55AM) --> uses standard 1 hour script
at 1:55AM --> 2:00AM program starts --> using a custom 2 hour script which simply repeats 1 hour script's entries for a second time
1:59:59AM --> clocks turned back to 1AM
at 2:55AM --> the scheduler will presumably trigger the 3:00AM standard 1 hour program ...

CASE 2: March clocks turned forward
12:00AM program (started at 11:55PM) --> uses standard 1 hour script
1:00AM program (started at 12:55AM) --> uses standard 1 hour script
at 1:55AM --> 2:00AM program starts --> using a standard 1 hour script
1:59:59AM --> clocks turned forward to 3AM
at 3:55AM --> i assume my 4:00AM program will be started --> the result being that simply the 3AM scheduled program will be skipped

[radio42]

Yes all your assumptions and the cases seems to be correct.