This works in most cases, except my application sometimes needs to adjust the PC clock. If the PC clock is adjusted backwards in time, then these function wait longer than they should (since the end time is fixed in the future).
Given that and what Ion says: "For cases when the system clock is advanced discontinuously by an operator, it is expected that implementations process any timed wait expiring at an intervening time as if that time had actually occurred." I would consider the behavior (prolonged waiting) as a bug. Well, its even kind of showstopper one. Imagine a boost-based programm running into issue when ntp daemon adjust the clock backwards. Can you please distill a small test case demonstrating the problem for your environment? -- Slava