This can be interpreted two ways¹. Both have one thing in common, promise that "important systems" are unaffected ("hidden by the principal ones of the affair"). However, people won't be able to view pr0n ("the lady on the charcoal will no longer be in sight") and they'll get mad.

So the two possible interpretations:

Javascript date display problems were fairly common in early 2000, and for some sites whose webmasters had been sleeping or something, they still are. (People just don't believe it when the API reference says "Deprecated" or "It won't return the last two numbers, it will return century - 100"... =) Also, many pr0n sites used Javascript (according to many, to annoying extent.)

While IIS (the optimal server solution for pr0n serving, as shown by Mindcraft) didn't have any Y2K problems (much), Microsoft.fi had a bad enough date problem that it ended up to evening news.

So, while Nostradamus wasn't entirely accurate, he came close.

Now, I would highly appreciate it if these riddles could be solved in advance... they won't do much after they're solved.

Thanks to GURPS Y2K for pointing out what this bit was about =) translation of the text is from nostradamus-repository.org.

¹ In this context, anyway. Others have probably interpreted in a lot of many ways =)

A strange-looking beast, the Y2K has quite a long wheelbase to give the rider a chance of keeping the front wheel on the ground. Large
boreexhaust pipes direct the monster's breath towards unsuspecting car drivers behind.

As opposed to what most people (like KuRL in his wu) said, the Y2K "bug" was not the result of trying to save space. In fact, storing dates as series of decimals is a waste of space as opposed to using binaryintegers. No, the Y2K problem was, for the most part, the sole result of design flaws in COBOL, which for some braindead reason used 2 decimals for the year as its standard date format. And it was the result of programmers' misconception that software is retired in the same rate hardware is (i.e. every 3 to 5 years). This may the case for word processors, but it's definitely not the case with business-criticaltransaction processing systems or the like, running on big iron, where switching over to new software means that you can't do any business if it doesn't work right away, and that you will have very angry customers if there are undiscovered bugs. Also, that kind of software tends to be written to customer specification and therefore extremely expensive. You don't spend that kind of money and run that kind of risk if the old software still works. And so, it keeps running, on the 10th cycle of new hardware, with 3 layers of emulation underneath, for decades.