This Sunday morning at 03.00h we went back from Summer to Winter time. So at 03.00h, clocks went back to 02.00h. This means that last Sunday had 25 hours instead of 24 because there are two hours between 02.00 and 03.00h. mAirList didn’t handle that like it should be.
First, it refused to import 25 hours of programming that I had generated with my music scheduling software. The second occurence of the 02-03h was not imported. All the timings of this supplementary hour were set to ‘–.--’ and so there was no reference to the correct times this hours’ playlist should be added to the playback of the previous playlist.
I have an event each hour to load the next hours playlist into mAirList. So, at 2.55h, the playlist for the hour between 03.00 and 04.00h was loaded. Now, at 03.00, the computer time was reset to 02.00h, correctly. But the next event to load a new playlist was allready scheduled to load at 03.55h. This means that the playback machine would run out of music at the new Winter time of 03.00h and it would wait untill 03.55 for the next playlist to load. Which would mean nearly an hour of dead air.
Is this something that was overlooked in mAirList or is there a workaround in order to get the transitions from Summer to Winter time smoothly as it should be? (And the transition from Winter to Summer time as well).
Daylight saving is one of the most complicated issues in scheduling.
Generally, for summer to winter, all you have to do is to make one particular playlist two hours long instead of one hour, and adjus the fix time of the end of hour marker. It depends on your events which one it is. Just keep in mind that there is one hour in which no event will run.
For winter to summer, likewise, one playlist will be skipped. There was a bug in earlier versions that made mAirList schedule the next event execution for the “missing” hour (02:xx:xx), so it got never executed, but that is fixed in all recent v5.x versions.
As most stations in Europe have this problem to cope with twice a year, would it not be better to build a solution for handling this into mAirList? E.g.: define a day with 25 hours (summer -> winter time) and one with 23 hours (winter -> summer time) every year somewhere in the general settings?
Is a tricky issue. I had a similar issue when building PodBox.me recently (automated listen again service), thankfully I didn’t notice any major issue when the event actually happened.
It is really, really tricky. Trust me. And building a solution that works for one region doesn’t really make sense, because there are dozens of other time zones (and exceptions from the DST scheme) around the world.
And the software sometimes cannot even tell if it’s in summer or winter time right now, or if a particular time in the future is.
But if you know how your events work, it is really easy to work around it.