Chrony time synchronization on huge time diff
Your problem seems to be that you're trying to accomplish a six year time change by skewing the clock, and giving up after one day.
If the skew algorithm drifts the clock by as much as one percent - which is quite a lot - it will take six hundred years to skew the clock that much. Even if the clock stands completely still, six years will need to elapse to step it back by six years. The only way to achieve a six-year backwards time drift in less than six years elapsed is to run the clock backwards, and I don't think anything will react well to that. To do it in one day would mean running the clock backwards at slightly more than two thousand times the real-time rate!
My feeling is that running NTP servers that lie is a very bad idea, but if you insist on doing this, and you suddenly skew the server by any significant amount, you will need to forcibly alter the client clocks before they have any chance of syncing. This is most easily done by ensuring that the clients forcibly reset their clocks from the server at boot time (with ntpd, this is done with ntpdate at boot time; I don't know about chrony) and rebooting the clients.
If your time is way off (days or even months), time synchronization will not work ("it will take a long time") because NTP clients like Chrony adjust the clock gradually by slowing it down or speeding it up.
Append this line to your Chrony config (for example, /etc/chrony.conf or /etc/chrony/chrony.conf):
makestep 1 -1
Then restart Chrony.
# systemctl restart chronyd
# or
# /etc/init.d/chrony restart
Explanation:
The makestep directive can be used to allow chronyd to step the clock. For example, if chrony.conf had
makestep 1 3
the clock would be stepped in the first three updates if its offset was larger than one second. Normally, it’s recommended to allow the step only in the first few updates, but in some cases (e.g. a computer without an RTC or virtual machine which can be suspended and resumed with an incorrect time) it may be necessary to allow the step on any clock update. The example above would change to
makestep 1 -1
https://chrony.tuxfamily.org/faq.html#_is_code_chronyd_code_allowed_to_step_the_system_clock
If the time difference is huge chrony might not accept your source. My clock was a few years back and chronyc tracking was reporting:
> chronyc tracking
Ref time (UTC) : Thu Jan 01 00:00:00 1970
What worked for me was to add maxdistance 1000000000 in /etc/chrony.conf and then (after chronyd restart) do chrnoyc -a makestep 1000 -1.