Just my 2 cents out of a long life Experience in Aviation.

Am Anfang dachte ich, dass ich die EASA und FAA Vorschriften gleichzeitig einbauen würde, aber ich habe sehr schnell gemerkt, dass ich so nie auf den grünen Zweig kommen würde. Der Kopf kocht ganz schnell wegen der feinen Unterschiede wegen Instrument- und IMC-Zeit, XC, Nacht und was auch immer. Deswegen habe ich beschlossen, dass ich erst mal das mache, was ich jetzt brauche und zumindest eine Regulatorik richtig verstehe.

Mein langfristiger Plan ist es, auch Tracklogs zu archivieren, dann kann ich hoffentlich, wenn ich jeweils die neue Regulatorik unterstützen muss, teilweise Informationen aus den Logs ziehen. Aber auch das ist nicht so einfach. Foreflight loggt die Sachen oft nach Lust und Laune getrennt oder zusammen und es gibt keine Möglichkeit, die Logs einfach zu editieren. Deshalb bin ich noch nicht so weit... Man muss sich überlegen, wie man das abbildet. Am einfachsten wäre es, eine Datei an einen Log-Eintrag anzuhängen, aber siehe Foreflight-Problematik.

Und am Ende bleibt immer noch etwas, was nicht berücksichtigt wird. Beispiel automatische Bestimmung Tag/Nacht: Nimmst du da für die Startzeit den Startplatz und die Landezeit den Landeplatz? Streng genommen beginnt die Nacht ja zu einem konkreten Zeitpunkt an dem ich dann gerade bin. Ist bei einem normalen Streckenflug mit maximal 300kts in Mitteleuropa kein Problem. Aber was ist mit einem Flug aus dem polaren Sommer in die Dunkelheit? Was ist mit Flügen über den Pol? Was ist mit Flügen die zweimal die Tag/Nacht-Grenzen passieren? Das Problem ist immer nur so trivial, wie man es gerade vereinfacht hat.

Und am Ende bleibt immer noch etwas, was nicht berücksichtigt wird. Beispiel automatische Bestimmung Tag/Nacht: [...]

Das habe ich mir auch überlegt - der Plan ist also, automatisch einen Vorschlag zu berechnen und ein Warndreieck anzuzeigen, wenn die Daten nicht mit der Automatik übereinstimmen, aber auf jeden Fall werden die Zeiten in der Datenbank gespeichert und nicht on-the-fly berechnet.

Das ist vor allem deshalb wichtig, weil mein typischer Workflow so aussieht, dass ich zuerst die Sachen in Vereinsflieger für die Abrechnung eingebe und dann die Flüge automatisch in mein Flugbuch importiere.

"Aber was ist mit einem Flug aus dem polaren Sommer in die Dunkelheit? Was ist mit Flügen über den Pol? Was ist mit Flügen die zweimal die Tag/Nacht-Grenzen passieren?"

Diese Fragen beschäftigen mich seit Jahren.

Programmiertechnisch würde ich das so lösen:

1. Zerlege den Grosskreis in Minuten-Segmente. Man erhält dann ein Array aus Datenpunkten mit Positionen und Timestamps.
2. Rechne für jeden Datenpunkt des Arrays aus, ob dort die Nachtdefinition erfüllt ist.
3. Summiere die Datenpunkte mit "Nacht" auf (jeder Punkt entspricht 1 Minute Nacht).

Aber ich vermute mal, die Aussage war eher ironischer Natur :-)

Warum erinnere ich mich gerade an eine Geschichte aus dem großartigen "Die letzten ihrer Art" von Douglas Adams ?!?

Ein Vogel irgendwo in Asien hat es geschafft, das läßtige Brüten zu "automatisieren", indem er nicht mehr selber die ganze Zeit auf dem Ei sitzen muss, sondern einen Bruthaufen baut. Dieses über dem Ei angehäufte Laub erzeugt durch Verrottung genau so viel Wärme, dass der Brutvorgang "automatisch" abläuft.
Leider ist der arme Vogel aber nicht nur vor der Eiablage längere Zeit damit beschäftigt, den Haufen zu bauen, sondern auch während des Brutvorgangs die ganze Zeit damit beschäftigt, durch rauspicken von Blättern an einer Stelle und hinzufügen an anderer, die Temperatur am Ei optimal zu regeln.

Mit nur 6 Wochen arbeit hat sich dieser schlaue Vogel 2 Wochen brüten gespart (oder so ähnlich).

Aber so wie nicht jeder die Ironie von Willi versteht, haben auch Willi +3,67 Grüne Bewertungen nicht verstanden, dass es bei meinem Einwand mitnichten um die praktische Betrachtung der Führung des Flugbuchs geht, sondern darum, dass der Fluch des Softwareentwicklers die implizit angenommenen Vereinfachungen sind.

Ein schönes Beispiel dafür sind Namen von Menschen: https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/