This bug was reported in our internal bug tracker and assigned to me.
At first, I disagreed that it was a bug but surprisingly there exist users who are running into this problem. We are making images for using in Vmware, and we don't know beforehand what time zone uses the client who installed image. So we are assuming that BIOS time is in UTC. But VMware hypervisor sets BIOS time to the local time! It can't be changed judging by googling results and reading several discussions on the subject. The operating system starts up in Moscow (UTC +3), then interfaces are being brought up by usage of dhclient, then goes NTP synchronization - and time goes back on three hours. With short leases, it leads to the bringing ifaces down.

I've made two solutions with gettimeofday() replacements: using LD_PRELOAD and other solution using direct compile-in replacements. Both of the solutions were quickly approved by our corporative code review. I've even put the somewhat simpler LD_PRELOAD hack on public githup. So it is not a problem for now, but it will be cool to know that someday it will be properly fixed in some future version.

Now I am going to nicely blame our support QA now by rephrasing your words that from 1993 there wasn't any person except them who bumped into this problem.

2017-07-11 18:49 GMT+03:00 Francis Dupont via RT <dhcp-confidential@isc.org>:

On Tue Jul 11 15:06:25 2017, kunschikov@gmail.com wrote:
> Again can be easily checked by usage of `strace`.

=> hum, it seems your solution (change the gettimeofday
clock for a monotonic one) is the only one which does not
require some redesign/recode...
Two notes:
- I have a tool for DNS which increases exponentially
the clock speed. It is used to check re-signing & co.
It is based on redirection of the gettimeofday system call
in a very similar way...
- unfortunately your solution won't work between reboots
so you have to remove the client lease file to reset the
state (this file is used at startup as an optimization and
is not critical at all, BTW many clients have no stable
storage so should not depend on it).