Instead of blindly assuming those two missing digits are 19, make the assumption that if they're less than 50, it's 20, and if it's greater than 50, it's 19.

2050 (or whatever cutoff they're using) will suck (again) if that was their solution.

If that's the solution, it seems like you can just make a code change every 50/100 years or so to increment the assumed century, and then this fix can work indefinitely for fairly low maintenance cost

It will work for incoming data, but it will also trash all your existing records.

You might not care about records that are 100+ years old, but you might.

I don't think that's an issue because I would presume you write your existing records with an absolute timestamp (unix time) rather than a relative one? Am I missing something?

A lot of these systems were built such that date stamps were simple 6 character text fields within a larger ascii-based file format on computers build in the 60s and 70s or earlier.

Space (both RAM and storage) is a premium on these systems and therefore much thought is given to what you place within any given row. As a result, no one stored unix timestamps as that would have required 10 characters more per timestamp per row, which would have had other ramifications on other parts of the code and/or memory. It would have required all stored records to be re-written somehow, which depending on the available online storage may have been an impossible task in and of itself. Not to mention how one would handle the recovery of any existing backups.

Due to these complexities, most organizations settled for code that shifted the meaning of the 2 digit year by some predetermined offset.

I would be happy if my code only had a bug every 50 years.