Best Practices for Daylight Savings

[thomas00111111111]

Are there any Best Practices to adhere to concerning Daylight Savings around jobs?

Are there White Papers that discuss this issue?

Thanks in advance.

[Marc Clasby]

I think each case might be different and you'd have to test for your situation so I don't think you'll find a policy.

We used to set system queue to zero during the time switch...

Not on Tidal 6, we currently let it roll as we didn't see any negative impacts during overnight processing. All our windows servers are 2012 R2. We also don't have jobs that absolutely locked in at a certain time that coincides with Daylight savings. Agents will work on jobs if they were told do by the Master, stay active and report back when they are done regardless of time springing ahead or falling back.

[Tyler Theobald]

Thomas, I've been a TES admin for 13 years now, and have never really had to worry about daylight savings time through all the version starting back at early v5, at least with our "small to medium" installation.

Your mileage may vary, but I believe TES has handled that quite well through the years.  One key may be that we have little jobs running during 1am, which is our system maintenance window.

[Derrick Au]

Hi Thomas,

There aren't that many problems as Tidal is intelligent enough to handle time changes. With time rolling back an hour from 2:00am to 1:00am, Tidal will know that job has already run and will not kick off again. With time rolling forward, if you have repeating jobs an instance will get skipped--but the processing continues with subsequent instances.

BR,

Derrick Au

[Steve Atwood]

Hi Derrick,

This was not our experience last fall....we have many jobs that are recurring - including some that need to run every single minute around the clock - and all of those jobs simply stopped running for an hour.  Looking at how Tidal schedules recurring jobs, it sets the "next run time", so a job that runs every minute and finishes at 1:59 a.m. will have a "next run time" of 2:00 a.m....but since, during the time change in the fall,  the next minute is 1:00 a.m., the job simply sits for an hour until 2:00 a.m. actually rolls around.

We had assumed that we would just have to deal with this - that it was simply how Tidal behaved.  I never really liked that answer, but looking at these comments that Tidal can handle the time changes with no problem, I'm beginning to wonder now if we should have opened an SR with TAC.  We're on 6.1, unix master & oracle db.

Anyone have any thoughts on this, am I missing something here, seems that I should open a ticket if this happens again this fall, no?

[rocketscientist1]

Steve,

I have experienced this problem when it comes to jobs which are required to run during the hour that is skipped or added during a DST switch.  In times past the short solution was for us to manually kick off those jobs during the hour differential or prepare the users to expect an hour delay in processing.

However, I have to ask.  If you are running a task on the minute, every minute, then why not daemonize the process instead of running through a scheduler?

[Steve Atwood]

rocketscientist1,

Sorry, just saw your post....thanks for the feedback.

I am right there with you on the job that runs every minute....if there was ever a true definition of a "cron" job, this is it....it needs to run every minute that the machine is up, even if the previous run failed.

But I lost that battle, they do want an "incident ticket" generated whenever it fails, and they need Tidal to do that for them.

[Richard Walewski]

My UNIX TES Master v6.1 is fine during the time changes but I found I need to reboot the Windows machine where my the TES Client Manager runs.

If I don't then it displays the wrong completion time in the OUTPUT tab (not critical to scheduling, just confusing to anyone revewing executions).