COBOL doesn't have a default date/time type
As such implementation decisions are left to the implementor
The implementors* of the SS system chose 1875 as the epoch date for reasons
*I made a lot of money in 1999. The original implementors of SS probably used something else ("it'll be rewritten before this is a problem" was essentially the whole raison de etre of Y2K). The 1875 thing, if it's a thing, was probably the result of Y2K work. But I have no direct knowledge of these matters.
The problem is we have no solid evidence that is actually true. The claim appears to originate in an anonymous DailyKos comment which contains so many factual errors (e.g. claiming this is due to COBOL), it is unclear why any of it should be believed. For all we really know, the SSA code doesn’t treat 1875 specially at all. And even if it actually does, are these social media claims that it does based on inside knowledge of how it works, or just a lucky guess?
That’s not to say DOGE’s claims about 150 year old social security recipients are right - for all I know, they could be wrong - but, if they are wrong, it could be for some reason which is completely unrelated to “1875 as an epoch”
Which would be true if it's the case.
Because I couldn't name any programming language people in use today that has no built-in date type.
But this isn’t true. COBOL 85 has builtin functions for representing dates as an integer from 1601 epoch. IBM mainframe COBOL supports two operation modes, ANSI-compatible mode in which those functions use the 1601 epoch, and IBM-compatible mode which use a 1582 epoch instead - https://www.ibm.com/docs/en/cobol-zos/6.4?topic=options-intd...
A lot of COBOL software didn’t use the COBOL 85 date functions because it is so old it long predates COBOL 85, and also because old habits die hard and some COBOL programmers avoided using them.
COBOL 85 doesn’t have a date type per se, dates are either integers (count of days since epoch) or strings (YYYYMMDD). But, C’s ‘time_t’ isn’t really a separate type (in the sense that many other languages have them) it is just an alias for an integer type. So COBOL is closer to C on this than you might think
"The implementors* of the SS system chose 1875 as the epoch date for reasons"
So, they invented their own date system instead of just using the standard CENTURY-DATE or an ISO-8601 date from their DB. Highly doubt...
Also the social media claim was that "this is how COBOL works", not "this is how the SS system works". It does not seem that the person who made the original social media claim has any insider knowledge of the SS COBOL system.
Definitely seems like misinformation to me.
If the claim is true and it's really a case of fraud, isn't that a case for the courts and DOJ to handle?
Or he is really trying to undermine trust in the government, like his false Gaza condom claim?
Logical theories include connected records include an age, its chaff unconnected to any money being moved retained for legal reasons, and them just making it up.
Since they won't substantiate this you can choose your own adventure whilst waiting for the boring truth which is probably on balance that all receipients have a known age but they were unable to look it up correctly and something somewhere returns default when not available i in that code path.
It's not a problem, since there are other ways of determining eligibility. If a person doesn't have proof of a birth date, what are you supposed to do? Make one up?
And the claim is that it's fraud, which requires evidence, not some anomaly which can be several things. Musk and DOGE deserve the "dunk" since they're spreading unsubstantiated BS.
There are of course going to be recently decreased not yet accounted for and a tiny number of fraudsters collecting grannies check.
Individual annual audits 200 USD per person would cost 136B over the next 10 years. Far more than fraud it would deter. Fraud which is already minimal.
Indivual audits of client accounts for obvious issues and fraud is already a thing because the experts that are responsible for such aren't complete morons.
You don't know what the recipient's details are, you're just saying it's a problem without knowing any of the facts around the individuals circumstances.
You're simply thinking in the most shallow way possible.
If that field is the qualifying field that it was presented as, Then any record with that data means you shouldn't be getting payments. And it was communicated that there are individuals getting payments with that dirty field.
Now you could motte-and-bailey the sentence "the technical details are irrelevant if there are people getting payments with those attributes it's a problem" by saying oh if any accounts in this group are getting payments, even if it's just a handful of them, that's a problem. But if we're talking about the number of these accounts being representative of the amount of fraud, there's no way that's true.
But uh, you don't think Musk was implying that? He decided to make an announcement that there were lots of super old accounts without any implication beyond their mere existence in a completely inactive state?
And I'm not going to ignore blatant implications to accept "oh he didn't say it".
Is it plausible that, given the claim is that people currently >150 years old are receiving money, in the previous 40 years of audits, etc., no-one has noticed that people >110 (vanishingly rare in the US) were getting money? That it took the arrival of Elon and his Special Boys with their cursory glance to immediately spot this problem that must have been missed by every other developer, tested, auditor, etc. for AT LEAST 40 years? Or that there has been some vast conspiracy - on both sides of the US political aisle - to keep paying out this money to clearly ineligible people without a single person ever whistleblowing?
My money is on the vastly simpler "Elon and his Special Boys[0] have misunderstood" hypothesis.
[0] who have not demonstrated a great acumen for being correct at any point, let's be honest.
It just says that basically each COBOL system will implement dates their own way.