Comment by karparov
5 days ago
20 may 1875 is the reference date of ISO 8601:2004.
You don't need to trust me on that, you can just go check the standard.
Or you can claim that it's misinformation too. Up to you.
5 days ago
20 may 1875 is the reference date of ISO 8601:2004.
You don't need to trust me on that, you can just go check the standard.
Or you can claim that it's misinformation too. Up to you.
Wouldn't you pause for a moment to consider how a 2004 standard is relevant to a COBOL codebase that is probably more than 50 years old at this point?
I'm not sure everything in there is 50 years old. Not even that everything is actually in COBOL. Those gigantic beasts tend to eventually be quarantined into some VM, never touched again, and then somebody puts some modern-ish wrappers around. For example some HTTP JSON API endpoints to query things. And what do they do when a date is missing? Not returning one would surely make sense. But I'd also expect layers and layers of abstractions in between, maybe some libs to transform some data type in one representation into another. Somewhere on the way, this date as a default value could easily slip in. It's not entirely made up, it's in an ISO standard. Maybe the lib was strictly following that standard.
It's not hard to imagine that something like this actually happened. Dismissing it outright just because COBOL does not have a datetime data type and the standard is only 21 years old (that far pre-dates node.js btw) could be playing into the hands of the Muskians who surely love any possibility to get out of this BS in case they made a mistake. Would not be the first they made nor the first they handled that way.
There is no cluster at 150 in the underlying data though, there's even distribution among unrealistically high age ranges. This is yet another case of people taking partisan telephone game conjecture literally.
1 reply →