How did the moon clock cope with this change – the first occurrence since we started? I think the answer is 80 %. Firstly, it did correctly recognise that BST had ended and this meant that npulse (the number of pulses needed at the end of each minute) was negative until the current time caught up with the displayed time. So the s hand waited for one hour. (I did not get up to watch this). In the morning, the moon was illuminated (it is near full moon with the moon up for 15 hours) and the s hand showed the right time. So far so good.
But the next test was whether the new rise and set times could be correctly displayed. The problem is that on the 27/28th October, the rise time was 19:45 and the set time was 10:51, whereas on the 28/29th October, the rise time was 19:30 and the set time was 11:56. So the rise time was 15 minutes earlier on 28th than the previous day. This was caused by clocks going back an hour. Since the clock can’t go backwards, it would have to go forwards about 23 hours and 45 minutes, needing 43,000 pulses. The algorithm decides that it is better to wait for 24 hours than to pulse this far, so it flashes the moon 500 times as an indicator. Unfortunately, the counter in the flashmoon function had somehow got deleted, so it was stuck in an infinite loop! This seems like a silly error when the hard part was working, but it shows how easy it is to make a mistake when editing. So I had to correct the error in the flashmoon function, adjust the rise and set times by hand and restart the clock.
Of course it will be a year until this situation arises again – when summer time comes into effect, times go forward and that’s not a problem.