Airline systems tend to have problems because they were written prior to 1980, when things like BCD were still commonplace.
For software written after approximately 1980 (and definitely after the dawn of 8-bit personal computers), the "Y2K problem" was rarely about date-storage and calculation, and was mainly a usability and character-mode UI problem.
First, let's get one thing clear: programmers in the 1980s and 1990s weren't oblivious to the year 2000. Behind the scenes, most programs written after ~1980 either represented dates as 32-bit epoch time values, or represented years as a byte offset from some reference year. The result is, they were generally good for dates between around 1800..2050 or 1850..2100.
The REAL problem was the ubiquity of 80x25 character-mode displays. Especially back in the 1980s, wasting two characters of screen real estate on a seemingly redundant '19' was intolerable. The arrival of Windows and proportional fonts made programmers more willing to start using 4-digit dates starting in the early 1990s... but for charactermode programs, there was intense resistance even in 1995, with 2000 less than 5 years away.
In many cases, Y2K mitigation was REALLY an excuse to scare management into approving the replacement of DOS and terminal-based programs with Windows. The truth is, almost all programs written after the 1970s HAD arcane work-arounds to let users enter pre-1900 and post-2000 years, and they weren't really a secret... just ugly and kludgy. Like, entering/rendering dates after 2000 using a letter as the first character (ex: a0=2000, b1=2011, c2=2022, etc). Or rendering dates like 2004 as 19104 (naively printing it as "19" plus the byte-offset from 1900).
The irony is, a lot of systems that were supposedly remediated for y2k ACTUALLY have ticking time-bomb deadlines of 2038, or sometime around 2050 or 2100 that have been mostly forgotten about by now.