Right. Instead of setting up their own secure date and time server or ensuring devices can establish a secure channel to a time server regardless of the circumstances, they decided to use SSL certificates to securely get the date and time? Which is an issue because the unix time stamp can have anything in it. Not only that, but it’s enabled by default, meaning that most server hosts won’t think to disable it until it starts causing problems. Right. And no one thought that this would be an issue?
I’m not a professional, but if I were to take a guess as to why the bug is becoming more common, it’d be that it’s probably self-perpetuating. One server gets the wrong unix time and flips out. Then, while IT is trying to fix the server, another server just kinda yoinks the SSL certificate from the bugged server to check the unix time. That server now has the wrong time too. However, this server doesn’t have anything time-sensitive on it (or at least nothing urgently affected by the time bug), and the error corrects itself by the time anyone notices. In the meantime, another server has borrowed that server’s SSL certificate, again, to check the time, and gets the wrong time as a result. Throw in the fact that there may be some people who, either out of maliciousness or for some niche application, have their systems intentionally misreporting the unix time, and voila!