Thanks to the math required for date conversion, the 2038 bug may actually show up a couple of years early. How do I know? I tried setting the clock forward in an embedded system I wrote the code for. Its calendar actually seems to fail in 2036. I haven't tried it in a while, but I think I can't even set the date past January 2036. I didn't try to figure out exactly why it failed earlier than it should have, because the library code looks pretty messy.
It's using the standard date library stuff from the IAR compiler, so I'm hoping that sometime within 20 years there will be an option to select a 64-bit compatible time/date library, and it can just be recompiled. At least I used time_t for everything related to Unix date values... I think. Also, the hardware it runs on only has a 32-bit counter for the RTC clock, but I'm sure that it could simply check the high bit, and add 2^32 after the rollover.
But he's not doing what SpaceX is already doing.
SpaceX is going into orbit, while Bezos is staying in the sub-orbital tourist ghetto with the likes of Virgin and XCOR.
OH BOY! A BASE ON THE MOON! Yeah, sure, maybe it would have happened by 2029 at the rate NASA works these days, have you seen how the Senate Launch System keeps missing its milestones? And what exact value is a base on the moon? A lot of scratchy moon dust to give everybody silicosis? Helium-three (giggle) for (hahaha) fusion power (giggle *SNORT*)?
An orbital space station is much more useful because we need to learn to do things in zero-gee (like, say for getting to Mars), and the moon ain't gonna do that.
No, that would be "Crashing App Grinds Dozens of Flights to a Halt".
The proper image should be of large copper cables attached between planes and large metal stakes in the ground.
I think that's a likely cause. I doubt they're updating the app (executable) on a regular basis and pushing the update, when it's only the data that changes regularly. All it takes is one glitch in a weekly data update, and one bad switch statement to cause a program to crash.
Proper error handling is one of the most important things in keeping things running (especially in unattended systems), but one of the harder things to get right, because it's hard to test (as in QA) for every possible unexpected input. You have to get a bit paranoid with your coding, because garbage input really is out to get you.