3 ms·

Allow me to present a possible theory: 1) Assume Social Security has a field called "verified birthday by US birth certificate" which is a timestamp measured i

Allow me to present a possible theory: 1) Assume Social Security has a field called "verified birthday by US birth certificate" which is a timestamp measured in days. 2) Assume this timestamp starts on May 20, 1875 which was once a COBOL epoch standard. 3) Assume if someone does not have a verified birth certificate that field will be 0. 3) Assume one of Musk's junior engineers runs a query against the SS database on this field. 4) Assume said engineer runs the results through an AI trained to spot various kinds of fraud and asks it to spot anything unusual. 5) Assume the AI spits out "We have found X million records matching fraud parameters since ages are over 120 years old." 6) Assume said engineer excitedly runs over to Musk with the results and Musk does not bother contacting anyone at the Social Security Administration to see if there is a logical alternative explanation other than fraud since he never bothered to check the $50 million worth of condoms to Gaza claim.

skissane 2y ago
> 2) Assume this timestamp starts on May 20, 1875 which was once a COBOL epoch standard. Was it? I've never heard of that date in connection with COBOL before. I've heard some people try to connect it to ISO 8601, but I think that's a misinterpretation – yes, the text of some versions of the ISO 8601 standard refers to that date, but only as a fixed point of reference to formally define the ISO 8601 timescale – really an editorial choice which makes no difference to implementations of the standard, which aren't supposed to treat that date in any way specially, and I'm not aware of any that actually do. Furthermore, the reference to this date in ISO 8601 was apparently only inserted in its 2004 revision, while surely this system is much older than that Now, it isn't impossible that some SSA computer system actually does use "1875-05-20" as some kind of "sentinel" value. Sentinel values like that are actually quite common in legacy systems. But if it does, I don't think it is because it is following any kind of widespread standard (whether COBOL or ISO 8601), I think it may just be an idiosyncrasy of the SSA or of that particular computer system. But, here's my own guess as to what is happening here: some random anonymous DailyKos commenter has come up with a speculative, and ultimately incorrect, guess as to why DOGE is wrong – and people all over the Internet are now repeating it, because they like what it says, and don't know enough about the technical details involved to realise it is likely wrong. It wouldn't surprise me if SSA computers don't treat the date "1875-05-20" specially at all, and that is just an invention of this commenter Which is not to say DOGE's claims are right – it is entirely possible that they are wrong – just not for this reason, for some other reason instead...
- throw0101d 2y ago
  > Was it? I've never heard of that date in connection with COBOL before. Which COBOL? COBOL for AIX: > The beginning of the Lilian date range is Friday 15 October 1582, the date of adoption of the Gregorian calendar. Lilian dates before this date are undefined. * https://www.ibm.com/docs/en/cobol-aix/5.1?topic=times-feedback-token https://www.ibm.com/docs/en/cobol-aix/5.1?topic=times-feedba... COBOL for z/OS > DATE-OF-INTEGER […] A positive integer that represents a number of days succeeding December 31, 1600, in the Gregorian calendar. The valid range is 1 to 3,067,671, which corresponds to dates ranging from January 1, 1601 thru December 31, 9999.* * https://www.ibm.com/docs/en/cobol-zos/6.4?topic=functions-date-integer https://www.ibm.com/docs/en/cobol-zos/6.4?topic=functions-da... So two COBOLs, from the same vendor (IBM), have different epochs. More: > CEECBLDY: Converts character date value to the COBOL Integer format. Day one is 01 January 1601 and the value is incremented by one for each subsequent day. […] > CEEISEC: Converts binary year, month, day, hour, minute, second, and millisecond to a number representing the number of seconds since 00:00:00 14 October 1582 * https://www.ibm.com/docs/en/zos/2.5.0?topic=services-basics-using-date-time https://www.ibm.com/docs/en/zos/2.5.0?topic=services-basics-... See also: > I have seen COBOL epochs in active use of 1600.01.01, 1875.05.24, 1900.01.01, 0000.00.00, 1970.01.01, 2000.01.01. and others. * https://old.reddit.com/r/ISO8601/comments/1ipikj5/those_who_do_not_expect_iso8601_shall_be_punished/mcychah/ https://old.reddit.com/r/ISO8601/comments/1ipikj5/those_who_...
  - skissane 2y ago
    You cite two COBOL implementations which use 1582 or 1600/1601 as epoch dates – that's not evidence that any COBOL uses 1875-05-20 as an epoch date. Then you cite an pseudonymous Reddit comment which claims they've seen a COBOL implementation using 1875-05-24 (not actually 1875-05-20, although maybe they meant to say 20 and the 24 is a mistake) – but can't even tell us what it is named. Maybe, somewhere out there, is a COBOL implementation which actually does use 1875-05-20: but if nobody can name it, we don't even know that it exists. And even if someone actually succeeds in digging up the name of a COBOL implementation using 1875-05-20 as an epoch date, can we be sure that is actually the COBOL implementation SSA is using?

skissane 2y ago

> 2) Assume this timestamp starts on May 20, 1875 which was once a COBOL epoch standard. Was it? I've never heard of that date in connection with COBOL before. I've heard some people try to connect it to ISO 8601, but I think that's a misinterpretation – yes, the text of some versions of the ISO 8601 standard refers to that date, but only as a fixed point of reference to formally define the ISO 8601 timescale – really an editorial choice which makes no difference to implementations of the standard, which aren't supposed to treat that date in any way specially, and I'm not aware of any that actually do. Furthermore, the reference to this date in ISO 8601 was apparently only inserted in its 2004 revision, while surely this system is much older than that Now, it isn't impossible that some SSA computer system actually does use "1875-05-20" as some kind of "sentinel" value. Sentinel values like that are actually quite common in legacy systems. But if it does, I don't think it is because it is following any kind of widespread standard (whether COBOL or ISO 8601), I think it may just be an idiosyncrasy of the SSA or of that particular computer system. But, here's my own guess as to what is happening here: some random anonymous DailyKos commenter has come up with a speculative, and ultimately incorrect, guess as to why DOGE is wrong – and people all over the Internet are now repeating it, because they like what it says, and don't know enough about the technical details involved to realise it is likely wrong. It wouldn't surprise me if SSA computers don't treat the date "1875-05-20" specially at all, and that is just an invention of this commenter Which is not to say DOGE's claims are right – it is entirely possible that they are wrong – just not for this reason, for some other reason instead...

throw0101d 2y ago
> Was it? I've never heard of that date in connection with COBOL before. Which COBOL? COBOL for AIX: > The beginning of the Lilian date range is Friday 15 October 1582, the date of adoption of the Gregorian calendar. Lilian dates before this date are undefined. * https://www.ibm.com/docs/en/cobol-aix/5.1?topic=times-feedback-token https://www.ibm.com/docs/en/cobol-aix/5.1?topic=times-feedba... COBOL for z/OS > DATE-OF-INTEGER […] A positive integer that represents a number of days succeeding December 31, 1600, in the Gregorian calendar. The valid range is 1 to 3,067,671, which corresponds to dates ranging from January 1, 1601 thru December 31, 9999.* * https://www.ibm.com/docs/en/cobol-zos/6.4?topic=functions-date-integer https://www.ibm.com/docs/en/cobol-zos/6.4?topic=functions-da... So two COBOLs, from the same vendor (IBM), have different epochs. More: > CEECBLDY: Converts character date value to the COBOL Integer format. Day one is 01 January 1601 and the value is incremented by one for each subsequent day. […] > CEEISEC: Converts binary year, month, day, hour, minute, second, and millisecond to a number representing the number of seconds since 00:00:00 14 October 1582 * https://www.ibm.com/docs/en/zos/2.5.0?topic=services-basics-using-date-time https://www.ibm.com/docs/en/zos/2.5.0?topic=services-basics-... See also: > I have seen COBOL epochs in active use of 1600.01.01, 1875.05.24, 1900.01.01, 0000.00.00, 1970.01.01, 2000.01.01. and others. * https://old.reddit.com/r/ISO8601/comments/1ipikj5/those_who_do_not_expect_iso8601_shall_be_punished/mcychah/ https://old.reddit.com/r/ISO8601/comments/1ipikj5/those_who_...
- skissane 2y ago
  You cite two COBOL implementations which use 1582 or 1600/1601 as epoch dates – that's not evidence that any COBOL uses 1875-05-20 as an epoch date. Then you cite an pseudonymous Reddit comment which claims they've seen a COBOL implementation using 1875-05-24 (not actually 1875-05-20, although maybe they meant to say 20 and the 24 is a mistake) – but can't even tell us what it is named. Maybe, somewhere out there, is a COBOL implementation which actually does use 1875-05-20: but if nobody can name it, we don't even know that it exists. And even if someone actually succeeds in digging up the name of a COBOL implementation using 1875-05-20 as an epoch date, can we be sure that is actually the COBOL implementation SSA is using?