Particularly on mainframe systems like airline reservation systems tend to run on where the Y2k fix in a lot of cases for Cobol was to simply contextually know that certain fields couldn't have been created before 2000, so '00' BCD is simply year 2000.

On our database systems, we have some date fields for which the default value should never, ever be used and if it is, there is a big problem. All of those dates are set to the dates of well-known natural disasters that happened in the 1800s or earlier.

The thought was that it needs to be something that isn’t believable to a non-technical user seeing it on their computer screen. It turns out that this is not necessarily useful. I listened to a guy talking about some issues with a record; he says “1871? What’s up with that?” And then just moved on as if “well it came out of the computer, must be right” or something.

I think that databases need to have the concept of NaN for dates and time stamps, except that this should be configurable to something like a poop emoji or something like ⁉🆘. It has to be something where your grandma would look at it and confidently say “your computer is broken”

> I think that databases need to have the concept of NaN for dates and time stamps, except that this should be configurable to something like a poop emoji or something like ⁉

How about just NULL?

"The server returned an unexpected error."

Now GLHF!

Making database columns nullable isn’t a free ride.

In some situations, you are trading one known point of failure for a million unknown ones. Among other problems :)

So have another column adjacent to the date that stores an enum with an error code with a reason for why the date is missing. My point is, this is business logic, doesn't have a universally applicable definition, and should be handled on a case-by-case basis rather than trying to hard-code it into the date type in the DB.

Default date types, with some columns being nullable, work just fine for my project. I wouldn't want them to be more complicated and force me to consider additional cases, especially if those cases aren't language compatible.

> How about just NULL?

Off topic, but this reminded me of:

Hello, I'm Mr. Null. My Name Makes Me Invisible to Computers

https://www.wired.com/2015/11/null/amp

Your database should not allow invalid values to exist. That is what check contstraints, foreign keys, NOT NULL constraints, etc. are for.

If you're such a DBA, the rest of an enterprise will quickly route around you.

That's the attitude that causes these problems. Probably their date was set to 1/1/2000 because the database wouldn't allow them to not set a date.

It's definitely some default (or "null" in a DB) value and that is exactly what OP is insinuating.