Is Support Automatically Handle Time Drift?

[gowy222]

Hi,

For long long time, I’ve been looking for a timer or cron job solution that can automatically correct time drift without requiring manual resets. In particular, it’s important that the tool can cope with these three scenarios:

NTP-Induced Drift (±1–2 seconds every 5 minutes)
In my openwrt environments, the system clock is adjusted by NTP roughly every five minutes, causing small forward or backward shifts of about one to two seconds. Does this tool detect and correct those minor drifts so that scheduled jobs (e.g., running every minute or every five minutes) continue on the intended cadence without intervention?

Manual Clock Rollback to 1970
During testing or debugging, someone might deliberately set the system clock all the way back to January 1, 1970. After such an extreme backward jump, will the tool’s internal scheduler automatically reset or realign its baseline so that future tasks still execute on a forward-moving timeline (rather than firing based on a “1970” timestamp)?

Manual Clock Forward Jump to 3010
Conversely, if the system clock is manually advanced to a far-future date (e.g., year 3010), can the tool detect this large positive jump and re-anchor its schedule (treating it as a “large jump” event) so that jobs do not all immediately fire or remain suspended until 3010? Ideally, scheduled tasks should resume their normal cadence without needing manual correction.

In summary, does this project/tool automatically handle:

Frequent NTP adjustments of a few seconds every few minutes,

Extreme manual rollbacks (e.g., to 1970), and

Extreme manual forward jumps (e.g., to 3010)

so that scheduled tasks always run at the intended intervals? If support exists, what configuration options enable this behavior, and how does the tool behave internally when a manual clock change occurs?

Any detailed explanation or example configuration would be greatly appreciated.

[Hexagon]

Hello!

Croner works with an internal timer that re-align when at most 30 seconds have passed (see line ~50 of croner.js).

If the time shifts while there is less than 30 seconds to next trigger, it will trigger as initially scheduled. If time shift when there is more than 30 seconds to next execution, it will re-evaluate the time of triggering according to the new time.

[Hexagon]

I'lll convert this to a discussion