Home > Article > Backend Development > [Translation]PHP millennium bug (y2k compliance), _PHP tutorial
[Translation]PHP millennium bug (y2k compliance), _PHP tutorial
- WBOYOriginal
- 2016-07-13 10:21:591201browse
[Translation] PHP millennium bug (y2k compliance),
The clock is inexorably approaching the last year of 2000, and Sayers predicted unprecedented doom for the next year. Computer glitches occur in every conceivable area. Often referred to as the Year 2000 problem, or the Y2K bug, this situation is easily explained. The procedure explains that the XX act begins on Form XX date 19th in 2000 and thereafter for the following year. If your birthday is "2/2/05", will you be 101 years old in 101 years, or one year?
Cost estimates for fixing this bug run into the billions of dollars, at least that much money that could threaten a recurrence of protracted legal fees due to real and alleged damages. As a result of these devastating cost projections, there is increasing pressure on businesses and governments to use secure, legally binding statements that all software is guaranteed to be Year 2000 compliant.
As you may guess, this pressure often stems from lawyer-wary insurance companies, which are quite afraid of death-by-litigation, even more than the actual cost impact they may have, resulting in losses. To defend themselves against legal risks, organizations around the world rush to safety, in all possible haste, to certify that software such as this is Year 2000 compliant. They intend to wield some kind of legal protection when the inevitable chaos strikes, righteously declare themselves free of Y2K contamination and redirect lawsuits against the signatories of said document.
Remember this: If someone asks you to guarantee that your 2000 software is defect free, they are just looking for an excuse to sue you if they misuse your software, even if it should happen to be their own fault. Perhaps they have forgotten the terms of their software license, which may read closer to the following:
Neither the author nor the distributor shall be liable to any party for direct, indirect, special, incidental, or consequential damages arising out of the use of this software, documentation, or any derivatives thereof, even if the author advises of the possibility of such damages.
The author and distributor specifically disclaim all warranties, including but not limited to the implied warranties of merchantability, fitness for a particular purpose and non-infringement. This software is provided on an "as is" basis and the author and distributor have no obligation to provide maintenance, support, updates, improvements, or modifications.
Have you ever stopped to wonder just how long an automaker could survive such government scrutiny as an anti-warranty? Why are software makers any different? Somehow, though, they seem to be. Whether something like this will survive the litigational madness in the courts that is sure to ensue in the years to come remains to be seen. Don't expect anything.
About Y2K Anxiety has reached an increasingly fever pitch in most large organizations. Every few days, you see something else in the popular media predicting a certain amount of disruption. Nearly all of these reports are peppered with vague prevarications or technical confusion. That's not to say that there isn't a real problem here, and we can pretend nothing bothers us. The answer is of course yes. But what the problem stems from and what can be done about it are, at best, often misunderstood. Usually three repeated lies aggravate the situation.
Three lies about the Y2K epidemic
The first lie usually told is that the Y2K problem historically came from the memory of expensive computers last year so dear, that programmers maintained the date in a two-digit format to control the cost.
This statement is obviously wrong. Think about it. How much does a two-digit number need to be stored? Two bytes, 16 bits? No, let alone: numeric data is rarely stored in text format because a more compact representation is readily available. A two-digit year will be a number ranging from 00 to 99. Can be represented in as little as 7 places.
How about using the full year, 1985 or 2010? The numbers would probably be represented in 11 digits. Are those veteran programmers really gleefully grabbing the speed savings of 4 whole bits/date? Surely precious hardware might be spared 4 bits! Even if not, one can use an offset from a reasonable base. If only the last two digits were used, the year date might represent not the absolute value, but the number of years since 1900. If so, this would still fit those mentioned 7-bits, at least for a while. Adding another point brings us clear to 2156. Ending question. Saving memory is not why this is done.
Although day users can choose non-expandable representation of the year, with the year as %1900 instead of 1900, this does not make it a hardware cost issue. It's still a short-sighted, soft design mistake.
The second lie is that this phenomenon is brand new. In the year 2000, countless systems will suddenly fail. This kind of thing has never happened before. Think about the ancient old man who was born in 1895. A program that reads their birthday as "95" will not pay them a few months to check since 1998, when they appear to be only three years old. The year 2000 did not happen in this equation. The so-called "year-2000" problem is not fashionable, nor is it limited to that year. Then it will be more obvious.
The third, and by far the most serious, lie about the Y2K problem, is that your company can protect itself from harm, whether true or not, by acquiring a compliance affidavit, or litigation. It can't. This belief in legal documents is actually hollow and dangerous. The wisest thing to do is to correct your deception immediately.
Insidious, the underlying root cause of the entire problem is either hardware or software. No, that's too easy, we know how to fix it. Apply for a few hundred dollars and lo and behold, everything is taken care of.
Unfortunately, that’s not it. The real problem is the wetware. That's right: the flaw lies not in our computers, nor in their programming, but in ourselves.
Most of the time, when people think of a date, they only use the last two digits. They write it on the check. They wrote it in the family Bible. Anytime you hear someone say, "I remember as far back as '65," or "'98, when the foundations of their collective consciousness were shaken by America's staggering failure in the Caribbean," you should know what they mean. Is this just 65? Speaker assumes life, it could be 1965 Is it just 98? Why, it's not that year, but back in 1898, when Spain lost what was left of its shabby empire to the upstart new worlders. In both cases, you can infer ambiguity from context, but if you don't have context, then you can only guess. And "Notorious".
The scariest part is that even if it is completely accurate and the computer program works and is obviously "Y2K compatible", you are still in big trouble. Take, for example, the famous Unix Carl program. Let's look at the current month.
$ cal 2 98 February 98 Su Mo Tu We Th Fr Sa 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 <br />等一等。那是什么?不是情人节应该是星期六,不是星期三,今年?哎呀,错了年!你真正要的类型是:
$ cal 2 1998 February 1998 Su Mo Tu We Th Fr Sa 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28As you can see, no matter whether the programs are compatible or not, because humans use them they are not! Fixing the programs is certainly a necessary step, but it is far from sufficient. You can prove every program exists and it's still not secure enough. Until the time comes when billions of people in the world - or even just the millions using computers - are equally authenticated and guaranteed not to be forgotten, there will be no security. This won't happen.
Seeking a legally binding statement that a particular program cannot be abused intentionally or unintentionally is nothing more than a witch hunt and is doomed to fail in its ultimate goal of protecting you and yours. You can't help, there will always be cluefully-challenged users and programmers, even clueless people who occasionally have memory loss. You can't find them, you can't blame tools or language, you can't protect yourself. Every time one thinks about a year in double digit terms, the problem arises again. And no one figured out how to solve the software problem.
Perl
What about Perl? Is Perl 2000 "compatible"? The answer is, Perl is as Y2K compatible as your Pencil, no more, no less. What about comforting you? This is not what it should be. Just like you could commit a Y2K bug with your Pencil, you could do it with Perl - or with any other tool, for that matter. And you really don't need to travel far to do it; witness the perfect compatibility Carl's demonstration projects offer.
The date and time functions provided by Perl are the gmtime() and localtime() functions, which are derived from their C programming language. These supply ample information to determine well beyond the year 2000. A crisis in 2038, only for us to still be stuck on 32-bit machines, is somewhat unlikely although admittedly not entirely unthinkable.
These functions return the year (in a list context), contrary to popular misconception, and are not defined as a two-digit number. On the contrary, it is just the way it is now. What it actually is, is the present minus nineteen hundred years. This happened for many years between 1900 and 1999 with decimal numbers, but this wouldn't last long. In order to avoid the year 2000 problem, the year is not regarded as a number at all. Easy to say, easy to break. Let's say you want to find out what this year seems to be within the last 5 years, so you write the code like this.
<tt> use Time::localtime;
$then = time() + ( 60 * 60 * 24 * 365 * 5 ); # 5 years from now
$that_year = localtime($then) -> year;
printf("It shall be 19%d\n", $that_year); # WRONG! 19103
printf("It shall be %d\n", 1900 + $that_year); # right: 2003<br /><br />如你所见,在坏人手中,甚至一个名义上的2000年兼容的工具如Perl或卡尔underclued或者仅仅是可以被滥用的健忘。<br /></tt>Perl has no warranty and TPI does not support Perl. Furthermore, Perl is a language, and languages can be abused in many ways. But that's the responsibility of the programmers and users, not the many creators of Perl. However, as Perl spokes-organization of the free software movement, we feel it necessary to point out that Perl is based on the same Y2K-compatible C language interface, and the Perl compiler and interpreter are written themselves. The Perl interface that accesses date information, when used as a design, is Y2K compatible in every sense of the word. If it makes your lawyer or manager happy, do them a favor. You still have a lot to worry about.
<tt> </tt>Original text: http://www.perl.com/pub/1999/01/y2k.html