On 01/08/2010 05:23 PM, Andy Wood wrote: >> No, >> >> The error was only dividing the last digit of the year by 4 to determine >> if it was a leap year. I.e. 92 is divisible by 4 but 2 is not. >> > > There must be plenty of ways of going wrong. > > However, the ones I recall were taking a two or four digit BCD year number, > and testing if it was divisible by four as if it was a binary number. For > example, > in assembler, using a TM instruction to check if the low order two bits were > both zero. By that method, or by actually doing a binary divide, X'1980' or > X'80' is correctly determined to be a leap year. It continues to work > correctly > up to 1989 but since X'1990' or X'90' is divisible by four, 1990 is taken as > a > leap. X'1992' or X'92' is not divisible by four, ergo 1992 is not a leap year > ... >
The case I remember was IBM's SDSF. The intent obviously was an overly-clever attempt to avoid the "overhead" of divides by using multiple TM instructions to test bits in the BCD year, determining leap year by looking for years 0, 4, 8 in even decades and years 2, 6 in odd decades (an algorithm for leap year determination which would first fail in 2100). The code was sufficiently obscure that a bug in the implementation of the algorithm wasn't obvious until it reported 03/01 as 02/29 in a non leap year in the 1990s. I don't know if IBM resolved this by just fixing the code to correctly implement the intended algorithm, or whether they also corrected the algorithm to handle the 100/400 year exceptions. If the former, this may be an example of a class of Y2100 leap-year problems that will surface in 2100 with the crossing of the first yy00 boundary that is not a leap year since the large-scale usage of digital computers. Discussions on public Y2K forums a decade ago showed considerable confusion over the 100/400 year leap-year exception rules. There were some adamant claims by those who didn't understand the rules (even by some technical types doing Y2K remediation!) that year 2000 would have 365, or even 367, days instead of the actual 366. This strongly suggests that some minor leap-year problems will be seen in 2100, either from code using an algorithm based on an incorrect understanding of the rules, or from code that took a shortcut to just ignore the 100/400 exceptions under the assumption that no descendant of that code would be running in 2100 when it next has an effect. -- Joel C. Ewing, Fort Smith, AR jremoveccapsew...@acm.org ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
