{
    "success": true,
    "data": {
        "id": 1209553,
        "msgid": "computer-in-2000-1447893297",
        "date": "1995-05-27 00:00:00",
        "title": "Computer in 2000",
        "author": null,
        "source": "",
        "tags": null,
        "topic": null,
        "summary": "Computer in 2000 The article published in The Jakarta Post on May 16, 1995 (page 8) under the title The Achilles heel of computers puzzled me. I would be very grateful if a computer expert, like Mr Zatni Arbi, could comment on it. The article gloomily predicts that the world's big computer systems would get stuck on Dec. 31, 1999, at midnight because they can't read four digits of a year. This seems to infer that language like COBOL are much imperfect.",
        "content": "<p>Computer in 2000<\/p>\n<p>The article published in The Jakarta Post on May 16, 1995<br>\n(page 8) under the title The Achilles heel of computers puzzled<br>\nme. I would be very grateful if a computer expert, like Mr Zatni<br>\nArbi, could comment on it.<\/p>\n<p>The article gloomily predicts that the world&apos;s big computer<br>\nsystems would get stuck on Dec. 31, 1999, at midnight because<br>\nthey can&apos;t read four digits of a year.<\/p>\n<p>This seems to infer that language like COBOL are much<br>\nimperfect. Why is it that other languages such as C and the<br>\nmachine language, and possibly others, are able to solve the<br>\nproblem? It is surely possible to modify COBOL to get it to read<br>\nthe first 2 digits of a date. Is it a herculean task?<\/p>\n<p>Meanwhile, I experimented on my own computers and I made some<br>\nstrange discoveries. As everybody knows, when you format a<br>\nspreadsheet range to date, any number typed in a cell of that<br>\nrange automatically becomes a date. Most spreadsheets let you<br>\nchoose a date format such as dd-mm-yy, dd-mm-yyyy, mm-dd-yy, etc.<br>\nWhen I choose a four digit format in, say, Lotus 1-2-3, I can<br>\nread, if the column width is sufficient, 21-06-1995 or 21-May-<br>\n1995.<\/p>\n<p>All date formats are deemed to start on January 1, 1900, which<br>\nhas the numerical value of 1 and increase by 1 every day: 30 is<br>\n30-Jan-1900, etc. I typed what I thought was the value for<br>\nDecember 31, 1999 and read 01-Jan-2000. The same happened to<br>\nQuattro but there, 1 becomes 31-Dec-1899! That discrepancy led me<br>\nto calculate the correct value for December 31, 1999.<\/p>\n<p>A century has, by definition, 100 years of 365 days each, plus<br>\nthe 24 extra February days of the leap years (1904,<br>\n1908....1996). Thus the total is 36524 which, in the cases of<br>\nLotus and Quattro, becomes 30-Dec-1999. Why? When you enter the<br>\nnumber 60, you must get 01-Mar-1900 but, in Lotus, it becomes 29-<br>\nFeb-1900, which did not exist: centuries are leap years only when<br>\ndivisible by 400, which was not the case in 1900, but will be the<br>\ncase in the year 2000. Correctly, Quattro does not have a<br>\nFebruary 29, 1900, but it got it right by cheating, i.e. starting<br>\nthe year 1900 with the number 2!<\/p>\n<p>As for Excel, it only shows the last 2 digits of the year but<br>\n60 shows 29-Feb-00. 36524 shows 30-Dec-99. Also wrong. Those are<br>\nIBM compatible programs.<\/p>\n<p>Other systems show similar differences. In one of my oldest<br>\nAmiga spreadsheets, entering 36524 gives me 31-Dec-99 (only 2<br>\ndigits there) but, when I add 1, the dates becomes, after<br>\nincreasing the cell width, 01-Jan-100! Maybe the program was not<br>\nwritten in machine language. A recent Amiga spreadsheet gives<br>\n36524 as 31-Dec-99 but is cheats twice: it shows 29-Feb-00 but,<br>\nto make the century end well, the number 0 is 01-Jan-00. Like<br>\nExcel, it shows only 2 digits and I can&apos;t tell what happens<br>\nlater.<\/p>\n<p>Mac spreadsheets are as wrong as Lotus. Next century,<br>\neverything should be back to normal, unless someone decides that<br>\nFebruary 2000 has only 28 days.<\/p>\n<p>ALEX WOLVESPERGES<\/p>\n<p>Medan, North Sumatra<\/p>",
        "url": "https:\/\/jawawa.id\/newsitem\/computer-in-2000-1447893297",
        "image": ""
    },
    "sponsor": "Okusi Associates",
    "sponsor_url": "https:\/\/okusiassociates.com"
}