this post was submitted on 22 Feb 2025
1642 points (98.9% liked)
Enough Musk Spam
2495 readers
1451 users here now
For those that have had enough of the Elon Musk worship online.
No flaming, baiting, etc. This community is intended for those opposed to the influx of Elon Musk-related advertising online. Coming here to defend Musk or his companies will not get you banned, but it likely will result in downvotes. Please use the reporting feature if you see a rule violation.
Opinions from all sides of the political spectrum are welcome here. However, we kindly ask that off-topic political discussion be kept to a minimum, so as to focus on the goal of this sub. This community is minimally moderated, so discussion and the power of upvotes/downvotes are allowed, provided lemmy.world rules are not broken.
Post links to instances of obvious Elon Musk fanboy brigading in default subreddits, lemmy/kbin communities/instances, astroturfing from Tesla/SpaceX/etc., or any articles critical of Musk, his ideas, unrealistic promises and timelines, or the working conditions at his companies.
Tesla-specific discussion can be posted here as well as our sister community /c/RealTesla.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.
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
Apparently ISO 8601:2004 doesn't exist?
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.
https://www.iso.org/obp/ui/en/#iso:std:iso:8601:ed-3:v1:en
Not true, I picked a random revision of the Wikipedia article from October 2022, and it already had the part about 1875:
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 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.
Why is your profile picture a lemming? Nowhere in the rust spec does it say that a lemming should be the default picture. This is just propaganda.
"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
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 epoch is a Unix thing. It may not apply to systems not related to Unix.
It's used in mainframes mostly. I don't know COBOL well but I've worked with COBOL systems in the past. I didn't think it even has a "date type" (at least in older systems? maybe it was added at some point?). They just store dates as 8 digits (6 back in the day which led to infamous "y2k" problems). That's why I didn't think they had an epoch. In more modern systems a date is typically "the number of milliseconds since the epoch". For Linux that's 01/01/1970. Either way this explanation for Musk's error is pretty sus. I'm sure he's misunderstanding something (he didn't think the US government used SQL ffs) though.
Edit: It's possible this particular team used that date as some sort of special value. That would be pretty common in older programming styles. But it doesn't seem like it's any sort of "standard."
Why not focus on the Nazi bit? Instead of lying about the 1875 bit? Are you lying about him being a Nazi?
Am I lying? No, I don't know anything about COBOL and haven't said anything about it either.