I think you have to read this one generously. The claim isn't about how COBOL works, except incidentally. It's more along the following lines:
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 implementors* of the SS system chose 1875 as the epoch date for reasons
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”
> 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
I did a lot of COBOL Y2K work in 1998-2000 and I have never once heard of any 1875 epoch related to COBOL until the last few days. We either modified code to use windowing functions or we just full converted to 4 digit years depending on severity. For instance, windowing code for front end, 4 digit years for DB, VSAM and flat files.
"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...
1875 being the result of Y2K work makes no sense to me.
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.
Only replying because playing same thought in head. Once two points relation exists. Simplest form distance. Either may be considered centre. Infinite points exist along that relation. And more can be imagined. The set of all points having the same distance from A as the distance from A to B etc.
The whole is better than the sum of the parts. You have nostradamus which predicts the future, fork bot which plays all playable presents, and the psychic friends network which rewrites the past. All under the watchful eye of the matrix.
There's something beautiful here and you honestly couldn't make it up.
It's not a bad thing on SSD storage maybe. On spinning platter hard drives, we may have to suffer a head seek time to get each field of the object from a separate record in the separate table. Whereas the fields of a record can be stored close together.
“Future users of large data banks must be
protected from having to know how the data is
organized in the machine (the internal
representation)… Activities of users at
terminals and most application programs
should remain unaffected when the internal
representation of data is changed and even
when some aspects of the external
representation are changed…”
Roll the related data up into materialized views for read performance.
But this is a bit silly surely? If they are different ways of talking about the same thing then one might as well label oneself a 'mentalist' and say "physical processes don't 'have mental effects', they just flat out are mental processes."
I think what you're going for is a species of monism maybe? The idea that Thought and Extension are attributes of one Substance?
We’re talking specifically about mental processes.
I think we agree that all weather is a physical process, but not all physical processes are weather. Similarly all mental processes are physical, but not all physical processes are mental.
Nevertheless it’s not that the physical atmospheric processes create weather as aside effect or product, they are the weather. Similarly mental processes are a class of physical processes.
Idealists take the opposite view. They think there are only mental processes and the physical is a class of, or product of mental processes.
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.