On an older Windows version, one day I lost internet connectivity on my machine and I didn't understand what had happened because the network interface was reporting that it was ok and the external connection appeared to be operating correctly.
Virus? Possible, but unlikely. A virus wants to spread, not limit its opportunities to do so.
After investigating, I was able to determine that the system clock somehow had gotten set past 2038 and this was sufficient to destroy network connectivity. As soon as it was corrected, everything was fine again.
Not the first time I have run into a clock issue breaking software.
We are lucky 2038 is still 16 years away and not next month.
There's parts of me that still think that 2020 will be the great shiny future, even though we all know that it turned out to be an epic bust. 2050? Can't see it from here.
SSL certificates are only valid for a slim date range, setting your clock too far ahead or too far behind will result in invalid certificates throwing errors.
I had a similar issue. I've also had issues with dual boot to Linux. When logging back into Windows the clock is always wrong. I have to turn on and off the automatic date setting function to get it to refresh.
You can fix that by forcing one or the other OS to use the time method the other one does. The issue is that by default one uses UTC and the other uses local system time.
Windows expects the system clock (the one you can set from the BIOS that keeps time when you don't have NTP) to be set to the local time zone by default. Linux and most other operating systems expect the system clock to be set to UTC.
Usually it's easier in a dual boot environment to set your non-Windows operating system to treat the system clock as local time, most Linux distros literally have a checkbox for this, but sometimes this isn't an option (IIRC Mac OS on a Hackintosh is one of these cases) and sometimes you just want to stand on principle that UTC is "correct" and make Windows adapt to what the rest of the computing world agreed on.
In that case, you can open up the registry, navigate to "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation", and create a QWORD "RealTimeIsUniversal" which is set to 1. Reboot and now Windows will treat the system clock as UTC.
Virus? Possible, but unlikely. A virus wants to spread, not limit its opportunities to do so.
After investigating, I was able to determine that the system clock somehow had gotten set past 2038 and this was sufficient to destroy network connectivity. As soon as it was corrected, everything was fine again.
Not the first time I have run into a clock issue breaking software.
We are lucky 2038 is still 16 years away and not next month.