I think this statement has a lot of explanatory power beyond the miscomprehension of the use of the default date in COBOL: "Everything is a conspiracy when you don’t know how anything works."
@karlykingsley.bsky.social the fact that these script kiddies are having to deal with horrible COBOL formatted data does give me a little evil joy
I'm pretty sure it was COBOL that gave me the fixed width columns, but with exceptions, data import nightmare I had once. That was old government data too.
@karlykingsley.bsky.social Valid - I didn't remember this, from my time using COBOL.
But also, I know if something seems odd, the initial assumption is a data problem, not corruption.
Musk and his kiddies tend to assume that the tech is perfect, which is really stupid and really naive. It comes from someone who knows nothing about tech, which fits.
@Stefan_S_from_H @karlykingsley.bsky.social
I asked ChatGPT-4o if it's "completely plausible that a Cobol program that tries to enter an uninitialized date variable into a database will accidentally write that 1875 date and get no error back?" and the bot confirmed that it is completely plausible.
I asked it what its current training cutoff date is and it said June 2024, which is before Elon revealed his incompetence regarding how Cobol can in some database environments use 1875.
@beeoproblem @Stefan_S_from_H That's why I suggested that he could use the bot to learn about Cobol and databases in that specific context, and not just ask a quick question and blindly trust the bot to not have hallucinated.
The bot can be really helpful in learning about a topic if you reason together with it, double check its claims and let it use its web tool to double check itself. There's also a big difference between "ChatGPT" and a specific variant of it such as the smart "ChatGPT-4o".
An article with more detail on the subject is referenced here:
https://mastodon.social/@thirstybear@agilodon.social/114007715107280514
@JeffGrigg @karlykingsley.bsky.social I'm looking for any code examples where I can replicate this.
It could just be that most open COBOL compilers are simply too new to be able to run into this issue. Do you know of any examples?
@tacnextgen @karlykingsley.bsky.social
It's not a COBOL specific thing. It's a government and international standards thing.
The United States National Bureau of Standards respects and adopts the rulings of the International Bureau of Standards, probably through some international agreements.
The metric system is a big part of this, but also various scientific measurement standards, including a "number of days since" standard.
…
@tacnextgen @karlykingsley.bsky.social
Doing a little research here, I see that what our government did is *NOT COBOL STANDARD*.
COBOL's "zero date" is December 31st, 1600. The international standard they used has a "zero date" of May 20 1875 — the date the group was founded.
…
@tacnextgen @karlykingsley.bsky.social
Our government may have preferred the later date, as it enables storing the birth date as a two byte unsigned integer — until some time near the end of the year 2054. I'm sure that in the 1960s it seemed like 2054 was in the "far distant future." (Kida' like the year 2000. 🙄 )
…
@tacnextgen @karlykingsley.bsky.social
So if you're going to save space and compute complexity by storing dates as "number of days since X" instead of "YYYYMMDD" (8 digits = 8 characters/bytes = 5 bytes in "packed decimal) then you have to choose the date "X".
@tacnextgen @karlykingsley.bsky.social
Relevant COBOL documentation, for your convenience:
https://www.ibm.com/docs/en/cobol-zos/6.4?topic=functions-integer-day
@JeffGrigg @karlykingsley.bsky.social
Much appreciated!
Edit: I've never played with COBOL before, and after a few hours, I now understand why some people come out of retirement and can charge insane consulting fees.
@karlykingsley.bsky.social it’s also entirely possible Musk knows this but is counting on the “normies” (in his words) not knowing it.
Show sharing it serves 2 purposes: laughing at him AND informing people of something they may not know.
Well done 👍
@TimWardCam @karlykingsley.bsky.social I've heard it can be for VARCHAR in PL/SQL
Also JavaScript's type coercion can cause some amusingly odd behavior with null if I remember right
I just remember getting calls for S0C7 ABENDs at 3 a.m.
@karlykingsley.bsky.social Musk: "Elves live among us, and have only begun registering their half-elf children into the Social Security program 150 years ago. The Truth is out there, sheeple!"
Most programmers: "Huh - there probably was a point where birth dates were optional when registering for social security - or someone had to convert YY/MM/DD dates into YYYY/MM/DD dates and didn't want to do it for the thousands of people already old enough to qualify."
@luatic @karlykingsley.bsky.social @JeffGrigg, elsewhere in this thread (just scroll), links to an article (link repeated here for convenience) and adds additional discussion of his own.
Is that what you were looking for?
Elon Musk claimed that his team found 150-year-old people collecting Social Security! He implied there were dead people being sent benefits, with checks cashed by someone else. But no—the people getting paid are very much alive. They are collecting...
@level98 @karlykingsley.bsky.social @JeffGrigg I'm afraid this just raises more questions than it answers. As many have pointed out for example, both COBOL and the systems in question are way older than the ISO standard.
For what it's worth, I asked on Retrocomputing Stack Exchange: https://retrocomputing.stackexchange.com/questions/31288/does-or-did-cobol-default-to-1875-05-20-for-corrupt-or-missing-dates
TL;DR: It's not a COBOL thing.
It's somewhat frustrating to see everyone repeat (or even falsely "confirm") unchecked claims because it plays into the right narrative.
@luatic @karlykingsley.bsky.social @JeffGrigg Both the article (update at end) and Jeff's thread, explain: yes, it is not a COBOL standard but an (old) ISO standard implemented on some COBOL systems.
In the thread you link: "Cobol doesn't even have a date type".
Dates (as commonly elsewhere) are stored as a number from a particular date.
Jeff conveniently references IBM Cobol docs stating "The INTDATE compiler option affects the starting date for the integer date functions"
etc.
@luatic @karlykingsley.bsky.social @JeffGrigg
So, either one takes the default or one can fix the start date and (as Jeff points out) fixing the start date to 20 May 1875 allows the use of a two byte unsigned integer.
As the article mentions, this date was in the ISO reference (so a reasonable/standard date to pick) but has since been removed.
@level98 @karlykingsley.bsky.social @JeffGrigg
Of course COBOL lets you represent dates somehow (though these would probably be strings, not numbers).
How you choose your epoch is not a COBOL thing, it's a business logic thing. It's something that could have been done in C or Lisp just as well.
All these assertive speculations about business logic annoy me.
So far Raffzahn's theory (that the epoch was picked based on the range of valid values) seems most plausible to me.
@luatic @level98 @karlykingsley.bsky.social
In my experience, dates in COBOL input/output records are often represented as EBCDIC characters. IE: Numeric digits.
Six and eight digit values are common, like YYYYMMDD or YYMMDD or (US) MMDDYY.
But to simplify computation, converting Gregorian "year, month, day" to "number of days since X" can make your life a lot easier. And save space, as binary numeric representations ar emore efficient.
Hahaha, fuck me.
@karlykingsley.bsky.social The sentence "Everything is a conspiracy when you don’t know how anything works" struck me so much I've written it down in my commonplace book.
It reminds me of all the nonsense around the 2020 election, when Trump cultists kept claiming things being done at counts were suspect, but always turned out to be normal counting procedures that they just didn't have any knowledge about.