Hacker News Reader

Comment by handojin | Hacker News Reader

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.

View on HN

> 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”

> claiming this is due to COBOL

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.

> 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.

Definitely seems like misinformation to me.

Reply on news.ycombinator.com