What happens to at jobs across the DST switch?

[Bo Berglund]

On Sat, 27 Mar 2021 07:44:15 +0100, Bo Berglund <bo.berglund at gmail.com> wrote:

>On Sat, 27 Mar 2021 12:37:28 +1100, Karl Auer <kauer at biplane.com.au> wrote:
>
>>BUT: I don't know whether at will properly calculate the time *for the
>>hour of changeover". Something for you to test. If the clocks go
>>forward at 2am where you are, set a task for 1:15 UTC on that day. It
>>should show a local time of 3:15, because at 2:00 UTC the local time
>>will have moved forward an hour, putting your two hours ahead in total.
>
>I decided to instead modify the script for the day of the changeover such that
>it starts a single recording at 23:59 the day before and runs this for 4 hours.
>This will make it encompass the whole changeoved hour inside and it probably
>just works then since the recording is set as a duration and not as a time to
>stop.
>
>Then tomorrow morning I have just to split the 4 hour recording into 1 hour
>segments as a one-off operation.
>

The verdict is in!

It turns out that my recording covers the intended 4:06 hours length, starting
at 5:59 PM Eastern Daylight Time.

The recorded file ends at 4:05 AM Central European Daylight Time as witnessed by
the timestamp on the file, so the recording continued for the programmed time
(4:06 hours). And the length of the video is in fact 4:06 in the video player.

But the *content* of the recording shows that at *exactly* the time of the DST
switch in Europe 3:01 into the video (9:00 PM Eastern Daylight Time) the
*content* of the video jumped ahead into some other unrelated show...
It looks like a repeat from Saturday morning or similar.

Conclusion:
The Youtube video stream itself, that was being recorded, had a time problem at
the exact time of the DST switch so the last hour of the content was lost.
Nothing I could have done to fix this. :(


-- 
Bo Berglund
Developer in Sweden