Daylight Savings Time; running scheduled tasks on time

Report · Mar 17, 2010

I am utilizing the scheduled tasks feature of ColdFusion (CF 8) so robustly, that we have had to dedicate multiple servers that do nothing but run scheduled tasks all day long. When Daylight Savings Time hits we always end up running into issues with tasks running early or late because CF8 decides to change the scheduled run time.

For instance, one task runs Daily at 23:20, and on Friday night after the task executed, instead of scheduling the next run for 23:20 EST on Saturday, it scheduled the task for 00:20 EDT on Sunday.

At what point does CF (or the JVM) change the time and why isn't it at 02:00 on the Sunday of the change?

What can I do to avoid this in the future, besides putting my servers into a state which doesn't observe DST?

We're using the JVM that came with CF 8 (1.6.0_04).

Any help is appriciated. Thank you.

Report · Nov 08, 2010

Did you ever figure this out? We are using a different JVM than what ships with CF8 (1.6.0_14) and we see the same behavior. It appears to only be the daily frequency jobs. In my case, when we fell back this weekend, I had a job that runs at 12:01am. It ran at 12:01am on Sunday, but then the log shows that it rescheduled it to run at 11:01PM on the same day. So, it's clearly adding 24 hours and then compensating for the hour gained during the switch to Savings time.

When we lose an hour in the spring, it simply does not schedule the jobs for a full day, so a day skips.

Again, I don't think it's a JVM issue, but I can't believe that no one else is having this issue and I can't find anyone talking about it.

Thanks,

Kyle

Report · Nov 09, 2010

Hi Kyle,

Well, I'm happy to see that I'm not the only person in the world trying to figure this out, so for that, Thank you.

We have not figured out what to do about this, other than to use GMT and not change the time at all. Since the servers are located in the Eastern Time Zone, that solution makes scheduling new tasks very confusing.

We have noticed that this past weekend, we have no issues with the tasks running late, early, twice or not at all. It only happens in the Spring when we lose an hour. My only other thought is to tell the OS not to adjust the clock automatically, and adjust the clock manually Sunday afternoon after all of the tasks have had their run and when we have a window larger than an hour with nothing scheduled. This way, they're all scheduled properly since CF already adjusted the task for its next run time...Or, do we ever need to adjust the clock in the OS if CF already took the adjustment into consideration?

As of now, I haven't figured anything out for sure, and really don't like testing on production systems. Too bad we can't just turn the change off in CF or Java...or can we?

Report · Mar 12, 2012

Did anyone ever figure out how to fix this? This is the first forum/blog posting about this issue that I've found and I've been looking for years.

I am seeing these same exact symptoms. I have 200+ scheduled tasks that run perfectly fine, but twice a year we have issues. It eventually fixes itself, but for the 24-48 hours after a time change it wreaks havoc on me.

Does CF9 fix this? I've read a post on Ben Nadel's log about storing my tasks in the database, but I really don't want to have to go through all of that trouble because of a seemingly simple bug. I guess not many people use Scheduled Tasks like we do.

Here is Ben's post in case you were wondering:

http://www.bennadel.com/blog/2237-Storing-Your-ColdFusion-Scheduled-Tasks-In-The-Database.htm

Report · Mar 12, 2012

Maybe define the current timezone will fix the problem.

Start up CF JVM with the following eg:

JVM Arguments

-server -Dsun.io.useCanonCaches=false -XX:MaxPermSize=192m -XX:+UseParallelGC -Dcoldfusion.rootDir={application.home}/../ -Dcoldfusion.libPath={application.home}/../lib -Duser.timezone=Australia/Sydney

Your timezone parameter will likely differ to Sydney. You may have other JVM settings pertinent to your environment with different perm and garbage collector settings. Can be a good idea to backup your JVM.CONFIG before applying any JVM changes.

HTH, Carl.

Report · Oct 30, 2013

Has anyone come up with an official solution to this yet?

A fellow developer was at last week's ColdFusion summit and the following solutions were suggested:

Turn off DST - We have over 100 custom internal applications that would need to be modified to manually handle this change. This is currently not feasible.
Build a custom task manager - This is do-able, but seems overkill to address a known bug
Turn tasks off and run them manually - This is currently what I will be doing until a solution is fixed.

Does the JVM argument suggestion above hold any water? Has anyone tried this?

Thanks,

Dave

Report · Oct 30, 2013

Hi Dave,

>Does the JVM argument suggestion above hold any water? Has anyone tried this?

I would not have posted it unless I tried it first and had a good outcome.

HTH, Carl.

Report · Oct 30, 2013

I haven't had an issue with CF tasks running at incorrect times, but I did have an issue with Oracle dbms scheduler tasks. In the end it was due to the timezone information in the JRE.

I ended up running the Java timezone updater (http://www.oracle.com/technetwork/java/javase/tzupdater-readme-136440.html)

Not sure if it will help your issue or not, but thought i'd mention it in case.

Cheers,

Simon

Report · Oct 31, 2013

Simon:

We are currently using tzdata2007g (http://www.oracle.com/technetwork/java/javase/tzdata-versions-138805.html). Looking through later updates, there doesn't seem to be any changes that would effect my timezone (unless they aren't documented on this page).

Do you remember what version you were running and what version you updated to?

Carl:
Didn't mean to portray any doubt, but it sounded more like a suggestion.

ColdFusion, Java, and the web server all seem to be reporting the same time zone, all observing DST (See below).

In your case, did you notice any discrepancies or was everything seeminlgy in sync?

ColdFusion:

LSTimeFormat: 7:31:45 AM EDT

GetTimeZoneInfo() - struct
isDSTon	YES
utcHourOffset	4
utcMinuteOffset	0
utcTotalOffset	14400

java.util.TimeZone:

getDisplayName()	Eastern Standard Time
useDaylightTime()	true
iInDaylightTime()	true
getDSTSavings()	3600000
getRawOffset()	-18000000

Server:

bash-3.00$ date

Thu Oct 31 07:39:40 EDT 2013

Report · Oct 31, 2013

Hi Malloy045

Our version was 2007f. I updated to the latest 2013g

Doesn't look like it will help given the various components all look to be in sync

Sorry it didn't help.

Cheers

Report · Nov 03, 2013

Sorry - being over a year ago that particular environment is not available for me to access and perform some tests. If I get a chance perhaps I can build a server with alternate time zone and try emulate matter.

Regards, Carl.

Report · Nov 04, 2013

Carl:

No need to do that - I just didn't know if you knew off hand.

UPDATE:

We went ahead and made the suggested changes (updating the tzdata file and specifying the timezone in our jvm arguments) and we still experienced this issue.

Last year was the first time I've had to deal with this and never had a clear picture of what was happening. I added additional logging to record the exact behavior of this task (note: this task runs daily at 00:50).

Here is what happens:

Nov 2 00:50 - Task runs as expected
Nov 3 00:50 - Task runs as expected
Nov 3 02:00 - DST adjustments made
Nov 3 23:50 - Task runs at incorrect time
Nov 4 00:50 - Task runs as expected

My knowledge of how the scheduled task feature is implemented is limited, but here is my best guess as to what is happening. It seems as if the task is re-scheduled correctly on Nov 4, for 00:50. When the time changes, CF re-evaluates the tasks and incorrectly compensates for the 1 hour change. This modifies the task start time to 1 hour earlier, which makes this task run on Nov 3 at 23:50.

In this particular task, the date and time at which it runs determines what data gets processed. This is where we experience the issues.

At this point, I'm leaning towards this being a CF8 bug. We hope to move to CF10 next year. I hope this addresses it.

Thanks for everyone's suggestions.

Dave

Report · Apr 28, 2014

this is logged as a bug here

https://bugbase.adobe.com/index.cfm?event=bug&id=3176293

When we came out of daylight savings recently in Sydney we had servers on CF8 AND CF10 run into this problem.

the re-scheduling doesn't apppear to work properly for DST.

i havent tried the JVM config change.

Report · Jan 20, 2022

Just wondering if this is still happening in CF2021.

Report · Jan 21, 2022

@brents78709329 , Come on, that was 11 years ago!

That was then CF8. There have since been CF9, CF10, CF11, CF2016, CF2018 and CF2021. If you have a question on this, please start a new thread of your own.

Report · Jan 21, 2022

Glad to see there's been improvements. This thread had been the only relevant search on the topic I came across. Here is my post that addresses my specific concern.
https://community.adobe.com/t5/coldfusion-discussions/timing-of-scheduled-tasks-when-server-and-clie...