How To

How do I configure the scheduler in IDM 5.x and OpenIDM 4.x to ensure JSON tasks are executed correctly when the time changes?

Last updated Apr 7, 2021

The purpose of this article is to provide information on configuring the scheduler in IDM/OpenIDM to pick up time changes (such as clocks going back an hour due to daylight saving time) to ensure JSON tasks are executed correctly.


This article has been archived and is no longer maintained by ForgeRock.


The timeZone field is deprecated in IDM 6 and removed in IDM 7; you should specify a time zone for schedules using the startTime and endTime fields instead. For example:

"startTime" : "2018-01-09T00:00:00.000Z", "endTime" : "2018-12-31T00:00:00.000Z",

Where UTC is specified by the addition of the Z.

See Integrator's Guide › Schedules and Daylight Savings Time for further information.

Pre-IDM 6

Scheduler timing is handled by the Quartz library in IDM/OpenIDM using the cronTrigger syntax. The Quartz scheduler adds a trigger to the list for the next scheduled task. If the time goes back before the task is executed, the trigger does not get modified and the next scheduled task gets missed as illustrated by this example:

01:59:59 - Schedule fires, Trigger created for 02:00:00 02:00:00 - DST Occurs, Clock set to 01:00:00 01:00:00 - No trigger, no schedule executed .. 01:59:59 - No trigger, no schedule executed 02:00:00 - Trigger found, schedule executed

This is a known shortcoming as described in the Quartz documentation: Quartz - Daylight Saving Time and Triggers. Clocks going forward an hour are handled correctly.

To avoid missing a scheduled event when the clocks go back, you can add the timeZone field to your scheduler (the schedule-<scheduleName>.json file located in the /path/to/idm/conf directory) and set it to UTC. The UTC setting ensures the scheduler uses Coordinated Universal Time, which does not follow a daylight savings schedule and retains the same time zone all year round.

Configuring the scheduler to pick up time changes

The following worked example shows the time zone being set to UTC and subsequent testing to prove that it handles time changes as expected. 


When re-testing, the Quartz library exhibits some odd behavior if the first invocation of the schedule is within a 1 hour window; to avoid this you should ensure the schedule fires at least once before this time elapses.

  1. Update your schedule-<scheduleName>.json file with the timeZone field. For example, the sample schedule-script.json file (located in the /path/to/idm/samples/example-configurations/schedules directory (IDM 5.5) or the /path/to/idm/samples/schedules directory (pre-IDM 5.5)) looks like this after setting the timeZone field: {     "enabled" : true,     "type": "cron",     "schedule": "0/2 * * * * ?",     "concurrentExecution" : false,     "invokeService": "script",     "timeZone" : "UTC",     "invokeContext": {         "script" : {               "type" : "text/javascript",               "source" : "java.lang.System.out.println('It is working: ' + input.edit);",               "input": { "edit": 26}             }     } }
  2. Shutdown IDM/OpenIDM in order to start testing: $ cd /path/to/idm $ ./
  3. Stop the ntpd Service (or any other auto-time services). Change the system time to a date and time prior to the clocks going back; this should also be prior to the time they will change to. For example in the US, you could use 00:30:00 AM EDT on 4th November 2018 (where the clocks go back at 02:00 AM on the same day). If you use the ntpd Service to sync your system time, you would use these commands: $ service ntpd stop $ timedatectl set-time "2018-11-04 00:30:00"​
  4. Restart IDM/OpenIDM: $ cd /path/to/idm $ ./
  5. Confirm that the schedule is executing within the IDM/OpenIDM console: Executing ./ Using OPENIDM_HOME:  /opt/openidm Using PROJECT_HOME:  /opt/openidm Using OPENIDM_OPTS:  -Xmx1024m -Xms1024m Using LOGGING_CONFIG: -Djava.util.logging.config.file=/opt/openidm/conf/ Using boot properties at /opt/openidm/conf/boot/ OpenIDM ready It is working: 26 It is working: 26 It is working: 26 It is working: 26
  6. Restart the ntpd Service (or any other auto-time services).  $ service ntpd restart
  7. With IDM/OpenIDM still executing, change the system time to a minute before the clocks are due to change (for example, 01:59:00 AM EDT) and monitor.  $ timedatectl set-time "2018-11-04 01:59:00"
  8. Observe the schedule continuing to execute within the IDM/OpenIDM console: It is working: 26 -> This is approximately when the time was changed to "2018-11-04 01:59:00" It is working: 26 It is working: 26 It is working: 26 It is working: 26 It is working: 26 As you can see, the "It is working: 26" lines continue even after the clocks go back to 01:00 AM EST, proving that the schedule continues to work after the time change.

See Also

FAQ: Task Scanner in IDM

Synchronization in IDM

Integrator's Guide › Scheduling Tasks and Events

Integrator's Guide › Configuring Schedules

Related Training


Related Issue Tracker IDs


Copyright and Trademarks Copyright © 2021 ForgeRock, all rights reserved.