You see that one node is showing synch issues, you realize is because the date time is incorrect in that node, in NTP it show one day ahead of the rest.
PAM 4.3.1
The time change can be done or manual, or by synching with NTP or taken from the vmware where PAM node is linked.
You did setting manual the time, rebooting the PAM node, and time was wrong again showing one day more.
The problem clock jumps did NOT come from a PAM administrator updating the time on the Configuration > Date/Time page. We would have seen the corresponding web service call in the logs.
The fact that after the reboot the very first kernel message has the bad time stamp strongly suggests that there was a problem with the clock on the physical server that the PAM VM was running on at the time. The time offset is too large for NTP to auto-correct it and the service eventually panics and exits, with all following restarts failing the same way until the clock is corrected by the PAM admin:
2026-05-05T08:45:35.545066+00:00 <server> ntpd[2723152]: CLOCK: Panic: offset too big: -85997.914
2026-05-05T08:45:35.546165+00:00 <server> systemd[1]: ntpsec.service: Main process exited, code=exited, status=1/FAILURE
Based on the PAM logs we conclude that this was an environment problem that is out of our control.
One item to investigate by you would be if there was any VMotion going on during the time frame of interest.