Monday, December 17, 2012

Orchestrator 2012 - Daylight Savings Time Scheduling Issue

I'm running a little behind on this post as Daylight Savings Time here in the US was back on Sunday, November 4.  For ease of example, all dates/times will reference the schedule for Daylight Savings in the United States.

There is an issue with scheduling Runbooks that start with the Monitor Date/Time activity during DST.

Daylight Saving Time (United States) 2012 began at 2:00 AM on Sunday, March 11.  At this time, 
the clocks would be moved ahead one hour to 3:00 AM.
  • This means any Runbooks scheduled to run between the hours of  2:00 AM - 3:00 AM would be skipped entirely.


Daylight Saving Time (United States) 2012 ended at 2:00 AM on Sunday, November 4.  At this time, 
the clocks would be moved back one hour to 1:00 AM.
  • This means any Runbooks schedule to run between the hours of 1:00 AM - 2:00 AM would run twice.

Depending on what the runbooks are executing, this could cause major issues and/or unscheduled downtime. It would also suggest Runbooks that are not set on an hourly interval (i.e. once daily) be scheduled outside of the hours of 1:00 AM - 3:00 AM to avoid any interruptions.  Unless you throw an exception into the schedule to work around the timing that the clocks are changed.

5 comments:

  1. Hi Jon,

    I have 4 different Orchestrator environments (development, integration test, system test and production). I have about 25-30 scheduled timers and I've read about issues regarding the daylight savings with Orchestrator. These timers are very crucial and I need to come up with a workaround for when the daylight savings happen (end of this march). What would you recommend and how should I solve this issue? We have about 170 runbooks running in production and I'm afraid it's gonna be a long sleepless night for me unless I get a workaround for this.

    Best regards,
    Leon Laude

    ReplyDelete
    Replies
    1. Hi Leon,

      The scheduling should only be an issue if you have monitor date/time activities scheduled in the hour before or after daylight savings takes effect. Anything outside of that would run as scheduled.

      Do you have runbooks scheduled once daily (or on the day DST falls on) to run in the hour after clocks are changed?

      Jon

      Delete
  2. Hi Jon,

    Ok, as a matter of fact we do use the monitor date/time in most of our runbooks. We do also have a few "once a day" scheduled runbooks that falls in with the DST which I'm afraid of. Most of our scheduled runbooks runs once daily, but we also have those that runs every 15/30/60 min.

    ReplyDelete
    Replies
    1. Hi Leon,

      Just wanted to post back results I observed from my environment. Here in the US daylight savings just occurred this past Sunday 3/13 morning. I currently don't have a workaround or solution to avoid any issues around start times and DST and it can differ on how runbooks are being invoked and setup across environments (parent/child). For the most part, I try to avoid scheduling runbooks that would run on a Sunday morning at this time.

      Spring Forward - Runbook Start Times

      2am: job runs twice (1am and 3am)

      2:01am - 2:59am: job runs one hour earlier

      3am: job is skipped

      Jon

      Delete
  3. Hi Jon,

    Thanks Jon for putting a lot of effort into this it is really apperciated.
    These test results is what I needed to know. I will have a talk with our business side and see how we can go around this during the DST.

    Thank you very much again!

    Best regards,
    Leon

    ReplyDelete