*****UPDATE*****
During testing we found that we had issues creating bookings given the examples below. If you look the timeline of the booking manager, you can see the time jumps from 1:59am to 3:00am (as expected). As a results, attempts to create booking with a preroll time between 2:00am and 2:59am fail since that time doesn't exist. MITIGATION: our original plan was to modify the pre-roll times on the bookings to account for the offset, but instead we're going to change the start time on the schedule so the booking can create.
ORIGINAL POST
With Daylight savings time approaching in the US this weekend, just wanted to confirm that we'll be OK for an SRM scenario...
We have two events on Sunday morning, one that starts at 3:00a with a 2:30a pre-roll and one that starts at 3:15a with a 2:45a pre-roll. Since the time change will go from 2:00am straight to 3:00am and thus skipping past the 2:30a and 2:45a pre-rolls, is there anything that needs to be done in advance to prepare for this? Or, does SRM have the necessary awareness of DST to handle these bookings to make sure the pre-rolls start?
Thanks!
I have no personal experience with this James, and you made a very good point. But I would say that you do have a problem at hand, because the time trigger for the pre-roll will never happen. 2.30a will never happen, and I believe the booking has to be configured with a pre-roll at 3.30a (because that is effectively the time that it will be at the moment that the pre-roll has to start) and a booking starting at 4.00a.
Thanks Ben… unfortunately the system is in Eastern, not UTC. I suppose this is a great argument for UTC in SRM deployments! We’ll do some testing in staging. I think you’re right though, we’ll have to manually adjust the booking times just to make sure the pre-rolls fire.
Note, the above is assuming the system is using a time reference that will effectively change. Because I know some operators run their systems on UTC / Zulu time.