Currently the following steps are performed to calculated scheduled checks:

1. split current utc time into components (days, hours, minutes...)
2. find the next matching time by applying scheduled check filters
3. convert the time back to utc

This can lead to gaps in polling times when using scheduled checks with polling periods less than hour, for example m/30. One way to fix it could be:

1. split current utc time into components (days, hours, minutes...)
2. find the next matching time by applying scheduled check filters
3. convert the time back to utc
4. check if the daylight saving status is different from the source time:
   1. find the daylight saving start time
   2. find the next matching time by applying scheduled check filters
   3. convert the time back to utc with the new daylight saving time status

Still this approach is more complicated and it's not quite clear what would be the best way to calculate daylight saving start time. A brute way would be using binary search to find the time when daylight saving status changes and cache it.