W32Time does not apply NTP correction with system clock set to 2056

I am investigating an issue with Windows Time Service (W32Time) in an isolated Windows environment.

The system is configured to synchronize with a trusted internal NTP server. Normal NTP communication works, but when the local system clock is intentionally set to 2056, W32Time receives the NTP response but does not apply the correction.

Tests already performed

We initially encountered 0x800705B4 timeouts. We investigated the network and confirmed that UDP 123 is reachable. Wireshark and w32tm /stripchart now show successful NTPv3 requests and valid server responses.

We also:

Verified the effective configuration with rsop.msc and found no unexpected GPO overrides.

Increased MaxPosPhaseCorrection and MaxNegPhaseCorrection to larger finite values.

Disabled Secure Time Seeding using UtilizeSslTimeData=0 and rebooted.

Configured the trusted internal NTP peer using the 0x8 flag.

Removed /reliable:yes.

Re-tested synchronization after the configuration changes.

The issue remains reproducible specifically when the local clock is set to 2056.

Question

Since NTP communication succeeds, is there a documented W32Time validation, timestamp/range limitation, or other internal condition that can prevent W32Time from applying a very large clock correction?

If 2056 itself is not a documented boundary, what W32Time diagnostic/debug logging would be recommended to determine why the received NTP sample is not being applied?

I can provide sanitized W32Time event logs and w32tm output from the test if required.