Previous implementation used number of milliseconds for scheduling. The problem was during scheduling every second, sometimes the process was too fast, under 1 millisecond. The last time lost the nanoseconds part, e.g. ZonedDateTime planned the next execution to the exact same time. Keeping nanoseconds forces planning to the next second.
Example of executions with schedule "* * * * * *":
Cron Trigger running, #4 at 19:30:22.302340267
Cron Trigger running, #5 at 19:30:23.000287937
Cron Trigger running, #6 at 19:30:23.303162670
Cron Trigger running, #7 at 19:30:24.000863731
The value 19:30:23.000287937 was converted to milliseconds, e.g. time 19:30:23 and the next schedule was 19:30:23 This is the behavior of CronTrigger, see its test: 2023, 4, 22, 12 -> 2023, 4, 22, 12.
This change uses ZonedDateTime instead of long, so it doesn't loose the nanoseconds and the next schedule after 19:30:23.000287937 is 19:30:24.
Previous implementation used number of milliseconds for scheduling. The problem was during scheduling every second, sometimes the process was too fast, under 1 millisecond. The last time lost the nanoseconds part, e.g.
ZonedDateTimeplanned the next execution to the exact same time. Keeping nanoseconds forces planning to the next second.Example of executions with schedule
"* * * * * *":The value
19:30:23.000287937was converted to milliseconds, e.g. time19:30:23and the next schedule was19:30:23This is the behavior of CronTrigger, see its test: 2023, 4, 22, 12 -> 2023, 4, 22, 12.This change uses
ZonedDateTimeinstead oflong, so it doesn't loose the nanoseconds and the next schedule after19:30:23.000287937is19:30:24.