Thanks for the screenshots and the logs. According to the host, UTC time is 13:09 - 60 mins = 12:09. According to the guest, UTC time is 14:09 - 60 mins = 13:09. Obviously, the VM is wrong. Something, and I'm not sure what that could be, seems to have set the guest's system time ahead by 60 minutes.
VMware tools does not step correct time backwards if it notices that the guest is ahead of the host, unless it's during startup or when time sync is enabled from the UI. Think of it as as a one-time courtesy before starting the service after which time can only be stepped forward or slew corrected (i.e., fixed in small increments over a long period of time).
Looking at the logs you have provided, tools time sync is detecting that the guest is ahead, and trying to fix it by slewing it:
2018-11-05T13:09:27.118+01:00| vcpu-1| I125: Guest: [ debug] [vmsvc:timeSync] Periodic synchronization: slewing time.
2018-11-05T13:09:27.118+01:00| vcpu-1| I125: Guest: [ debug] [vmsvc:timeSync] Slewing time: adjustment -3600479500
...
018-11-05T13:10:27.114+01:00| vcpu-1| I125: Guest: [ debug] [vmsvc:timeSync] Periodic synchronization: slewing time.
2018-11-05T13:10:27.114+01:00| vcpu-1| I125: Guest: [ debug] [vmsvc:timeSync] Slewing time: adjustment -3594479000
...
The adjustment value is in microseconds, and as you can see, the adjustment value reduces each sync period (which is every 60s). And you can imagine this is going to take a long time.
One thing that I am not able explain is why tools did not perform a one-time backward correction. For some reason it determined that it did not need to do that. I'll have to reproduce this internally to answer that.
Meanwhile, would you be able to look into what might have caused system time to be set exactly 1 hour ahead in your VM?
Thanks for your patience and for providing all the additional logs and info.