Windows/Excel is not (should not) be a benchmark for proper software development and function. Particularly in any applications where life safety is a factor.
And the whole 32-bit 2038 year is (or should be) a non issue. Properly written and compartmentalized software (object oriented for all the s/w geeks out there) hides the internal implementation of the time counter from the user. Nobody should be reading the clock variable directly, but calling the function that returns the proper value. Which, if written correctly, will correct for the overflow.
An earlier poster alluded to some of the problems with avionics s/w (Fortran style development). These include the heavy use of global variables: We can't fix something because we don't know who reads the 'broken' value, expecting it to be broken. So we have to add yet another function/variable to return a value usable to other routines (with its own quirks and anomalies, of course).
I've worked in the avionics engineering field alongside some 'so called' software engineers who continue to propagate spaghetti code. Some is due to management's refusal to get it fixed properly, but patch it and push it out the door. So they do the best they can. But some of it is due to their view of software as some magical 'thing' that stands aside from all other disciplines in the industry. Which no one else could possibly understand.