Windows' native API for dates consists of the types FILETIME and SYSTEMTIME which will handle 5-digit years, and even the old MS-DOS FAT timestamp goes up to 2107. The 2038 problem came from Unix and applications which use 32-bit Unix epoch time.
It's entirely possible somewhere in the stack of a 32-bit Windows application sits a DLL that uses POSIX time, stat, etc. functions and will fail in a similar way.
The 2038 bug is definitely expected, and unlike in Linux, with its highly distributed and composable architecture, management of fonts on Windows is a responsibility of the monolithic operating system maintained by one company.
It's not out of the realm of possibility, but I'd be a little startled if Windows hasn't already been gone over with a fine tooth comb for Y-2038 issues.
Windows stopped supporting 32-bit Windows (i.e., Windows 11 is 64-bit only). They still fully support 32-bit apps, of which a lot still exist. Visual Studio 2022 is the first version of Microsoft’s flagship IDE that is 64-bit, for example!
You could probably guess I don't claim to be authoritative here. :D I just recall there was a story not long ago about them doing some hard decisions going into 64 bit. https://learn.microsoft.com/en-us/troubleshoot/windows-serve... seems to indicate that you should mostly expect it to work.
Odds are high I just saw the headlines about how they are stopping 32 bit sales of their OS. Though, I couldn't tell you for sure what I was misremembering.
Apps will still overflow if they try to parse a 64-bit Unix timestamp using a 32-bit integer. If that's the case, I imagine they'll break in interesting ways.
