Everything happens 51 minutes too late

I don’t think so.
As you wrote, your server does not have a RTC. As I understood, the issue you are seeing is not noticed on systems which do have an RTC. So it is more like an issue outside of openHAB.
A possible solution could be to somehow delay your openHAB start until your server/OS did synchronize time with an ntp server, but then you have to rely on an internet connection.

Perhaps a feature request for openHAB to monitor the system clock(s), and if they change then do a bunch of rescheduling. Consequences will have to be thought through…

My installation also recovered after restarting - but I will certainly run into the same problem again when the VM running OH will be paused the next time.
Is there an easy way to view/access the different clocks coming toi play here? OS clock is clear but what about the JAVA clock and, proboably the most important, the clock being used by the rules engine of OH?

I’m not so sure.

That’s absolutely beyond openHAB’s control, of course.

But it is feasible for OH to detect large clock corrections, and possibly consider reschedulng.

Two “me too” in a few days suggests this is not uncommon, no doubt due to the Pi platform. I’ll bet it is quite extensive really, but not so many notice a 10-min slippage after reboot.

A possible solution within openHAB would be to postpone the start until time was synced.
This could be achieved by adding and additional parameter to openHAB.service :

[Unit]
Description=openHAB - empowering the smart home
Documentation=https://www.openhab.org/docs/
Documentation=https://community.openhab.org
Wants=network-online.target
After=network-online.target systemd-timesyncd
                            ^^^^^^^^^^^^^^^^^^

If you’ve disabled timesyncd in favor of ntp, then substitute the NTP service name.

Sounds a bit perilous to be honest - “My openHAB starts up but NOTHING HAPPENS!!!” Days later … “Oh the NTP server in Frankfurt came back online and now it works”.

It’s probably safer to do nothing by default - we can’t tell if there is any problem until/unless there is a large clock correction.

As said before, users would be addicted to a stable internet connection. timesync or ntp normaly have fallbacks, so an offline server should not be a problem though.
Any other solutions I can think off would need manual interaction :
openHAB needs to inform the user somehow about a time difference (how would this be calculated ???)
User then needs to correct system time (restart of openHAB needed ?)

That all starts with

  1. making the time difference visible for a human
  2. making the time difference visible for OH to eb able to correct or at least inform about time drift.

I can easily recreate the issue just by pausing my VM for x minutes - as probably everyone who hosts OH on a virtual machine.

Sure, the easy solution is to prevent using pause/resume for virtual environments but as @DanielMalmgren showed it also happens on hardware if timesync is not fast enough.
Oh, btw, Astro Binding also gets irritated and in my case triggered sunset 10 minutes too early.

Thankyou, this is good info.
Other bindings use the same scheduler e.g. for periodic polling. It’s giving me a headache trying to work out the consequences.
If we have a once-a-minute poll scheduled, which after clock correction is scheduled for 9 minutes in the past … uhhhh … in truth I think the scheduler is smart enough to run it immediately. But if not, there will be some weird “stopped working” effects here.

I don’t really agree. How OH should work intuitively is that if I schedule something to happen at a specific time it should happen at that specific time based on the current clock, not based on what the clock happened to be when OH was started. So it IS a problem within OH for sure, even though it is caused by things outside OH.

I think a sufficient “solution” would be to add a little passus in the docs about this, simply informing about that OH needs to be started after the server’s clock has been adequately set. And then every user can solve it according to their own needs. The problem is if nobody knows that this is a potential problem.

Just to be on the clear side: This actually isn’t a real problem for me. This was the first downtime I’ve had in years (really windy up here in Sweden lately) and next time I know what to do. And if it really bothered me I could just pop in the RTC battery, just haven’t bothered to do that :grinning_face_with_smiling_eyes:

Trouble is that it’s OH that is setting the clock, if NTP/DHCP in use.

But that does open the door to detection

Exactly one year later I encountered the same issue again so I tried to find something other than restarting OH itself.
First I checked the time in the Karaf-Console, that was on par with the system time.
As the rules were off by around tree minutes I restarted

199 │ Active │  80 │ 3.4.0                  │ openHAB Core :: Bundles :: Model Rules Runtime

which removed the offset of the clocks.