The description of LockSupport.parkUntil clearly says that the provided deadline is an absolute instant encoded as milliseconds since the Epoch.

<quote>
@param deadline the absolute time, in milliseconds from the Epoch, to wait until
</quote>

Unfortunately either this description is simply wrong, or the implementation has a bug, because it is pretty simple to prove that the command will fail in some cases, for example when a phase of hibernation happened between invocation of the command and the provided deadline.

Steps to reproduce:
* Use JDK 8u66 on Win 8.1 (64 Bit). [Mac will provide different behaviour!]
* Start the program below.
* Instantly close the laptop lid to begin hibernation.
* Wait for 30 seconds.
* Open the laptop lid to cancel hibernation.
* Wait until the program prints the test result.

	static final void demonstrateSchedulerSleepover() {
		final long requestedDelay = 60L;
		final long startTime = System.nanoTime();
		LockSupport.parkUntil(Instant.now().plus(1L, ChronoUnit.MINUTES).toEpochMilli());
		System.out.printf("Requested Delay: %ds / Actual delay: %ds%n", requestedDelay, (System.nanoTime() - startTime) / 1000000000L, requestedDelay,
				TimeUnit.SECONDS);
	}

Expected result:
* Exactly 60 seconds after starting the program it should print "Requested Delay: 60s / Actual delay: 60s".

Actual result:
* About 90 seconds after starting the program it does print "Requested Delay: 60s / Actual delay: 90s".

Conclusion:
* Either the software works as designed, then the JavaDocs are simply wrong as parkUntil will _not_ fire at the given instant but much later in case of intermediate hibernation.
* Or the software is simply buggy, possibly because it uses a Windows API that has changed its implication since the invention of this Java API, or possibly because it uses the wrong Windows API.

Impact:
* There might be application software that heavily relies on the fact that this API works correctly in both cases, with *and* without intermediate hibernation. "Correctly" here means that the software MUST fire at that absolute instant, unless that instant lies *within* the hibernation phase (in the latter case, an instant firing has to happen at the end of the hibernation phase). Such software will clearly fail due to the random length of the hibernation phase. Depending on the use case, this might be a severe problem for such kind of applications. Such software typically is  e. g. production control software (ERP), business management, frequent mail inbound checks, etc.