This is the very long tail of non-metric conversion that drives me insane.<p>This date format is unforgivable:
"td_id_fltdata_date": "00181219",<p>(1) add in leading 00 to allow for Y2k expansion (and then ignore it)<p>(2) DDMMYY This is unnecessarily "difficult" for a human and a computer to sort and parse. Using ALL the same number of digits and following ISO 8601 already solves this (and with the padding 00's you don't need to touch this part of the software for 7900 more years!)<p>20191218 - Done.
This can only be a holdover from a pre-PC era.<p>Some industries move at a glacial pace when updating standards and tools. The risk to lives because of screwups (i.e. a faulty radar at Air Traffic Control) is too great to do without sufficient study and experimentation. But this can only be an unwillingness to change.
Panasonic holds an almost monopoly on aircraft inflight entertainment, especially on widebody planes. They run redboot Linux and have a pretty strict firewall between the plane and computer. All of what the author did was expected by the Panasonic devs hence the disclaimer.<p>Ads-b carries a lot of this data (at a lower interval) and is available to anyone with an antenna. Sites like FlightAware will republish it as graphs or maps. There also exist apps that take ads-b data and renders flight data in a google earth type view.<p>A part of me is really excited that we live in this time, but I’m living in constant fear that open data will disappear one day, so enjoy while you can!
> I’ve never dealt with lat/long being formatted this way, so if you know how to parse it let me know!<p>I interpret departure_latitude = 39.525° N, departure_longitude = 75.135° W. Google Maps shows this to be Parvin State Park near Philadelphia.<p>Looking at your big JSON dump, I noticed these fields:<p><pre><code> "td_id_gmt_offset_departure": "80005.00",
"td_id_gmt_offset_destination": "00001.00",
</code></pre>
This suggests that a leading 8 (strangely in decimal rather than hex?) means negative sign. So your departure time zone was UTC-5 and your destination time zone was UTC+1.
Would be cool to be able to see some kind of a "geek passenger instrument panel" with this information during flight. This would definitely influence my choice of an airline.
Found the same thing a few years ago. Was a fun pastime getting the eta up on my desktop environment's status bar without having internet based documentation. From memory I used curl and jq.