<thread>: this_thread::sleep_until uses system time even if based on steady_clock #718
Description
Describe the bug
Internally, sleep_until calls _To_xtime_10_day_clamped to convert time point of any clock to time point of System clock. Then _Thrd_sleep sleeps on this system time point:
Lines 154 to 166 in 3141965
_To_xtime_10_day_clamped uses system_clock
Lines 629 to 652 in 3141965
If system_clock is adjusted between _To_xtime_10_day_clamped and _Thrd_sleep, the sleep interval is wrong.
sleep_for is also subject to this problem as it is based on sleep_until
Lines 168 to 171 in 3141965
Though standard says
The functions whose names end in _for take an argument that specifies a duration. These functions produce relative timeouts. Implementations should use a steady clock to measure time for these functions.
Command-line test case
Hard to build stable repro, but will try if needed.
Expected behavior
Neither sleep_until relative to a steady clock nor sleep_for should depend on system_clock.
GetTickCount64 is good enough steady clock, as Sleep API does not have granularity less than a millisecond anyway (calling undocumented NtDelayExecution is unacceptable). GetTickCount64 is very fast clock, it is basically reading a global variable.
STL version
Microsoft Visual Studio Professional 2019 Preview
Version 16.6.0 Preview 2.1
Additional context
Suspect that tests for #593 are failing due to timeout because other tests simultaneously tamper with system clock. Ok, this theory is defeated now, but the bug still looks valid