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.
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.
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.
- Shutdown IDM/OpenIDM in order to start testing: $ cd /path/to/idm $ ./shutdown.sh
- 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"
- Restart IDM/OpenIDM: $ cd /path/to/idm $ ./startup.sh
- Confirm that the schedule is executing within the IDM/OpenIDM console: Executing ./startup.sh... 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/logging.properties Using boot properties at /opt/openidm/conf/boot/boot.properties OpenIDM ready It is working: 26 It is working: 26 It is working: 26 It is working: 26
- Restart the ntpd Service (or any other auto-time services). $ service ntpd restart
- 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"
- 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.