Skip navigation
sroberts7101
Currently Being Moderated

Daylight Savings Time; running scheduled tasks on time

Mar 17, 2010 10:55 AM

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.

 
Replies
  • Currently Being Moderated
    Nov 8, 2010 2:10 PM   in reply to sroberts7101

    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

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 12, 2012 12:28 PM   in reply to sroberts7101

    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-Ta sks-In-The-Database.htm

     
    |
    Mark as:
  • Currently Being Moderated
    Mar 12, 2012 7:07 PM   in reply to kylemurphy2009

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 30, 2013 9:29 AM   in reply to sroberts7101

    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

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 30, 2013 12:38 PM   in reply to sroberts7101

    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

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 30, 2013 4:40 PM   in reply to malloy045

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 31, 2013 4:50 AM   in reply to sroberts7101

    Simon:

    We are currently using tzdata2007g (http://www.oracle.com/technetwork/java/javase/tzdata-versions-138805.h tml). 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

     
    |
    Mark as:
  • Currently Being Moderated
    Oct 31, 2013 5:17 AM   in reply to malloy045

    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

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 3, 2013 2:18 PM   in reply to malloy045

    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.

     
    |
    Mark as:
  • Currently Being Moderated
    Nov 4, 2013 5:01 AM   in reply to carl type3

    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:

     

    1. Nov 2 00:50 - Task runs as expected
    2. Nov 3 00:50 - Task runs as expected
    3. Nov 3 02:00 - DST adjustments made
    4. Nov 3 23:50 - Task runs at incorrect time
    5. 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

     
    |
    Mark as:

More Like This

  • Retrieving data ...

Bookmarked By (0)

Answers + Points = Status

  • 10 points awarded for Correct Answers
  • 5 points awarded for Helpful Answers
  • 10,000+ points
  • 1,001-10,000 points
  • 501-1,000 points
  • 5-500 points