The response is wrong. I remember reading an article that disproved it and explained the actual reason. However I forgot the actual reason.
COBOL doesn’t have a date type. And there were “people” in that “list” that weren’t just 150 years old, and they varied in ages.
The real answer is that the list that they’re saying is people getting social security, isn’t the list of people getting paid, just lists of random ages in the database, which ultimately means nothing.
They also found that there’s people over 200, so that default date thing doesn’t really explain it all.
It’s because that explanation isn’t correct. The real deal is you just have entries without a death date, so if you ran a query this get super old ages as a result.
Note that isn’t a database of payments or even people eligible for them, just a listing of ‘everyone’ with a SSN. There is a separate master death index. In the old days, wild west kind of stuff people would disappear so the death date would never get entered. Modern days every morgue and funeral home has to legally notify SS when someone dies, there is a specific form and major hell to pay if you don’t do it.
Social Security numbers were first issued in 1937. You would have need someone to be over 110 in 1937 to have an age over 200. I think that it’s a combination of birthdays entered wrong plus no official death date.
I think those are related to survivor benefits. Like an old man marrying a young woman in the 40’s. Like the civil war vets marrying woman in the 20th century. The last civil war widow was getting benefits until she died in 2020. But still the same basic issue.
But in that case the old man isn’t getting benefits but just is needed as a reference for the person actually getting them.
Also a lot of people between 110 and 150, so I’m sure there is a larger answer.
However, Social Security cuts off at 115, and they supposedly found like 10 million people older than that. Considering there are only ~50m people on Social Security, and the database they were searching wasn’t even about current recipients, most people would conclude that there is likely an error in data, rather than immediately jump to fraud. Of course, ketamine is a hell of a drug and Elon is not most people.
It’s definitely still concerning if the database has a large number of errors. But systematic fraud would be much worse ofc.
the database doesn’t have to necessarily be accurate if there’s other checks - a flag for test data, a system that checks the person is real against another database before dispersing funds etc
No one ever fucking lived to that age for fuck’s sake!
In that case I think “year” means “lunar cycle”. This makes a more natural age (80-something IIRC)
Maybe, but you don’t know that. You only know the data you have doesn’t make sense. You can’t just make something up and claim it’s correct: you have no way of knowing what the real data is , nor are you an authority
It’s probably logical to not pay out social security for 900 years, but that’s just an additional business process for handling bad data
I also have doubts about the correctness of the specific claim, but of course there’s bad data. How could there not be? That doesn’t mean you can claim fraud, it means you can check with the processes that keep money from being sent out where there is bad data.
I especially had a chuckle from the article where they said 90,000 claims are being sent out for people 100 yr old or more …… yet the claim is that 10 million of those are fraud?
1875 has never been an epoch anywhere, on any system. 1970 has. 1900 has. 0000 has. But 1875? No, it hasn’t. And no where in the cobol spec does 1875 appear.
This is just propaganda. He already does enough wrong, you guys lying about it just makes everything else you say suspect.
“You guys are wrong about the epoch in COBOL and it’s really making me believe this ketamine fueled Nazi, shame on you” lol you’re ridiculous
Why not focus on the Nazi bit? Instead of lying about the 1875 bit? Are you lying about him being a Nazi?
I thought truth mattered right?
…right?
I was intrigued by this article as 1865 isn’t any epoch I’ve heard about and I didn’t think COBOL really had a concept of an epoch (an epoch matters when you’re counting milliseconds from zero, COBOL stores date/time info differently). I’ve been searching this morning and can only find the Wikipedia page mentioning that date - which is weird for an ISO standard that is 99% about date formatting.
Yeah I’ve only heard of the 1970 epoch too, I didn’t realise different languages had different epochs honestly! Interesting stuff. I’ve never worked with COBOL but my old boss was learning it a few years ago, it’s used a lot in banking right?
That doesn’t mention 1875. Wikipedia was edited two days ago to add that in, it doesn’t appear in the original standard at all.
Wikipedia was edited two days ago to add that in
Not true, I picked a random revision of the Wikipedia article from October 2022, and it already had the part about 1875:
ISO 8601:2004 fixes a reference calendar date to the Gregorian calendar of 20 May 1875 as the date the Convention du Mètre (Metre Convention) was signed in Paris (the explicit reference date was removed in ISO 8601-1:2019).
https://en.wikipedia.org/w/index.php?title=ISO_8601&oldid=1118165613
I’m pretty sure this has been in the Wikipedia article for even longer, considering that it dates back to 2001. I’m just too lazy to go through the entire history and check when it was added. But definitely not 2 days ago.
Edit: I also just googled “ISO 8601 2004”, found this PDF: https://dotat.at/tmp/ISO_8601-2004_E.pdf
Under 3.2.1 “The Gregorian calendar” it says:
The Gregorian calendar has a reference point that assigns 20 May 1875 to the calendar day that the “Convention du Mètre” was signed in Paris.
The Wikipedia article is correct, this wasn’t added 2 days ago, and I don’t know why you’re spreading misinformation.
Another edit: A brief look at your profile explains everything…
Yet another edit: I checked the Wiki article using WikiBlame:
The part about 1875 was added to the article in 2004. Not 2 days ago. This is a blatant lie.
https://en.wikipedia.org/w/index.php?title=ISO_8601&oldid=4668168
Nowhere in the cobol spec because cobol doesn’t even have a date type. It’s more of a legacy solution to a nearly 100 year old problem.
A lot of people online are calling it a reference date, whatever that means. An epoch data doesn’t even make sense since there isn’t really a date time type. I can see reason to doubt, but that’s not relevant.
However it could be important to the app. Perhaps at some point they decided there needed to be a cutoff because anything older was bad data. OR perhaps back in the days where storage was extremely expensive it was important to save a byte for every row.
Even if the specific claim about 1875 is wrong, that doesn’t change anything. The reality is bad data exists, there doesn’t seem to be any indication of it being paid out, and the claim of fraud is assinine
