Events in Spring time DST run at 3 AM and use that for next run check
Article ID: 392228
Updated On: 03-27-2025
Products
Issue/Introduction
If an event is set to run not on the hour and a next run is scheduled between 2 AM and 3 AM on the Sunday of spring daylight saving time check, it will run at 3 AM and then use that for next run after.
For example:
Event runs hourly and is set to start 12:15 AM
On the DST Sunday, it will run at 12:15, 1:15, 3 AM, 4 AM, 5 AM, etc... instead of 12:15 AM, 1:15 AM, 3:15 AM, 4:15 AM ... or 12:15 AM, 1:15 AM, 3:00 AM (for the missed 2:15 AM), 3:15 AM etc...
Cause
This behavior is as designed
Resolution
This behavior is by design. The reason for this is around the how the next check is stored in the database. Currently it's stored in UTC and in past versions, it could cause problems if the next check on an event or C_PERIOD was in a certain timeframe that went beyond the day of the DST change - this caused looping on the WPs and a full outage. Because of these historical issues, the behavior was updated so that if something was scheduled to run between 2 and 3 AM during the spring DST change, it would just start at 3 AM and then the next check would be based on that run rather than the the run before that.
Moving forward, we will add in an example like the following into the documentation:
When you set up an interval where the object would be executed in the hour that is missed out by the time change, the object will be executed at the next full hour.
Example: An interval of 20 minutes has been set, the first check time is 01:49, then the next check time should be 02:09. But since that hour is missing because of the time change, your object will be executed at 03:00. So the interval would be 11 minutes long only in this one instance.
If your system has a setup where it is imperative that Events run always a certain number of minutes past the hour, this will need to be taken into account and there are a few options (please keep in mind these are just examples):
1) There is one recommendation that can help immediately which is for events that run a "manageable" number of times a day, use the schedule directly for these rather than use an event. "Manageable" really depends on the schedule, the event, and the team. Adding in twelve might not be too much work, but adding in 24 might be. That said, making the change once in a schedule can help overall with the oddities of events. For example, if something should run hourly at 15 past the hour, instead of using an Event set to start at 12:15 and run every two hours, add twelve entries into the schedule at:
00:15
02:15
04:15
...
20:15
22:15
This will prevent this next check issue with events form happening.
2) Another option is to be prepped for the spring daylight saving time change have an operations team ready to stop and restart events on the day of at the specific times needed.
3) Another way could be to have a specific calendar for the daylight saving time day events so that they kick off hourly up to 2 AM, then cancel, and have another event kick off only on the DST day that starts at 3:xx where xx is the amount of minutes after the hour that it should kick off and it can start hourly from there. For example, in the example above where something runs 15 minutes after the hour and and runs every 2 hours, you would schedule two single runs for 00:15 and 2:15 (will kick off at 3:00) and then an event to start at 4:15. This would require calendars and keeping track of these.
4) There is a kind of hybrid option between 1 and 3 above which could be to always schedule everything before 3 AM to be individual runs and then have events scheduled for anything that is normally scheduled after 3AM. For example, if something should run hourly at 5 after the hour, it can be scheduled for individual runs at 00:05, 01:05, 02:05 (will run at 3 AM on DST day in the spring), then an event scheduled to run every hour beginning at 3:05 AM.
Feedback
