Windows Server Date Issue: After setting the time to 13 Sep 2037 2:46:6 UTC and beyond, domain members cannot logon/apply GPO to the domain computers.

Question

While doing testing for the year 2038 issue, I found that domain logon or GPO application is no longer possible after setting the year to 2038. Also, trying to reset the date to 2022 was not easy. So do not try this on a production system. Will Microsoft be releasing a fix anytime soon?

Subsequent tests revealed that the problem actually starts at approximately 13 Sep 2037 2:46:5.0001 UTC.
Tests conducted on Windows Server 2022 produced the same problem.

One unusual behaviour was the change in error message in the timeline of failures:

1) From 13 Sep 2037 2:46:5.1 UTC to 13 Sep 2037 2:48:5.1 UTC, the error message was the same as that after 1 Jan 2038 0:0:0.1 UTC:

 There is a time and/or date difference between the client and server.  

2) From 13 Sep 2037 2:48:5.1 UTC to 1 Jan 2038 0:0:0 UTC, there was another different error message:

 The user name or password is incorrect. Try again.  

When the date is in the unsupported range and there is no user logon to be able to change the date:

1. The local accounts on member computers are still able to logon to set the time to a supported range.
2. For the domain controller, use a time server or DSRM to set the time to a supported range.
3. If testing with both server and client machines, then the client machine time can be synchronized with the server by running the command "net time /set" on the client. This works for both during testing and after testing. But this test is more complicated and is not recommended unless the the single server test scenario has been resolved.

Answer 1

Thank you for testing and reporting this issue.
In case you have access to a Windows 10 or Windows 11 device, try open start and search for feedback and open the Feedback Hub app and report this issue.
Make sure share steps to reproduce the problem and you may share them as different feedbacks like one for the domain issue and another to reset the date.
In case you observed any other issues , make sure file a report so the Microsoft will be able to reproduce and fix the issue.

Answer 2

Hello

-currently supported core OS and mainstream support products operate as designed and with no known negative impact with regards to the 2038 unless otherwise noted.
-SYSTEMTIME has no problems and can go until the year 30,827.
-FILETIME, a 64-bit integer (two DWORDs representing LOW and HIGH values) since January 1, 1601 (Julian). It too can represent a 30,000 (or 60,000 unsigned) year interval.

Programs that are compiled with VC8 or newer and do not define _USE_32BIT_TIME_T are immune to Year 2038 problems caused by time_t, assuming that they do not contain bugs themselves (casting a time_t to an int and back will truncate it). I’m told by the Developer division that…

VC7.1 (Visual Studio 2003) contained __time64_t (see http://msdn2.microsoft.com/en-us/library/1f4c8f33(VS.71).aspx ), but developers had to specifically use it. (It appears that VC6 did not contain __time64_t – see http://msdn2.microsoft.com/en-us/library/aa272948(VS.60).aspx – but VC6 is no longer supported, unlike VC7.1.)
we expanded time_t to 64 bits by default in VC8 (Visual Studio 2005). See http://msdn2.microsoft.com/en-us/library/ms235429(VS.80).aspx. Also see http://msdn2.microsoft.com/en-us/library/w4ddyt9h(VS.80).aspx, which explains that _USE_32BIT_TIME_T is provided for backwards compatibility.

---

--If the reply is helpful, please Upvote and Accept as answer--

Answer 3

This problem does not seem to exist for Windows Server 2025.