LMAO watch the US be saved by an inability of Muskys frat bois to understand COBOL
I dont even program and i could’ve told them it was probably a placeholder or default value lol “durrrrrr lot of people in this database were born at the exact same time on the same day in the same year that predates electronic databases, gotta be fraud!!1!1!11”
Eejit…
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.
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.
“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?
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
In before Musk says “You think the government uses COBOL?!”
I don’t think the government uses COBOL. I know the government uses COBOL.
Not only do many important government systems ultimately rely on or make heavy use of COBOL…
So do many older private companies.
Like banks. Account balances, transactions.
Its actually quite a serious problem that basically nobody who needs to take seriously actually does.
Basically no one is taught COBOL anymore, but a huge amount of code that undergirds much of what we consider ‘modernity’ is written in COBOL, and all the older folks that actually know COBOL are retiring.
We’re gonna hit a point where the COBOL parts of a system to be altered or maintained, and … there just isn’t anyone who actually knows how to do it.
My understanding is that even if you learn COBOL, you’d struggle to understand legacy systems since they have their quirks from a bygone era
That is absolutely true as well… though this may be just a personal anecdote, it seems to me that the few COBOL coders I once knew would be amongst the most likely to keep a solid documentation of their own systems.
The problem with that though, is that their bosses are almost always too stupid to ask them for such documentation before they leave/retire, or to bother to preserve it when the exiting COBOL programmer gives it to them, because coding is magic to them, and you’re either a good magician that can do the thing, or you’re not.
Upper management / C Suite seems to never understand why the term software engineer was/is used.
Yeah, I’ve been tempted to try this route, but you’re really pigeonholing yourself. Even if there’s always wrk, I can’t imagine only working with cobol the rest of my career.
Even worse, the places still using this are very heavy in process, with many undocumented dependencies among many undocumented workflows and business processes. Modernizing COBOL is not a coding problem: it’s a mammoth project management, coordination, and paperwork project that also has a little bit of coding. And its not like you can write clean code, you need to write essentially the same tangled mess of accumulated changes over decades because there’s no way of knowing everything that might break
I hereby nominate you to be the new head of the SSA.
You get it, exactly.
COBOL itself is a fairly minor part of the problem, the real problem is the retiring COBOL coders are the only ones with enough institutional knowledge, broad and specific, to keep the engine from grenading and fucking wheels from coming off the car when it hits a bad enough pothole.
But management and C Suite are apparently homo superior, fully confident that none of that really matters, they’ll just keep throwing money at it until its fixed, and failing that, laying off everyone, who care in the end, they get a golden parachute when it all burns, everyone else can FOAD.
