Ist nicht ganz so theoretisch wie es sich anhört, ich muss das korrekt in einer Software implementieren, aber niemand, den ich gefragt habe, weiß mit Sicherheit wie dieses 'korrekt' aussieht.

Desto genauer man hinschaut, desto interessanter werden solche Fragen. Man kommt mal wieder zum Ergebnis, dass unsere Art die Zeit zu berechnen in einer globalisierten Welt nicht besonders gut funktioniert. Nicht ohne Grund rechnet der Informatiker oft in Millisekunden seit dem 1.1.1970 UTC. Das funktioniert besser...

Lustig sind immer Fragen im Studium wie viele Sekunden sind seit dem 1. Februar 1500 an Ort XY vergangen. Erscheint einfach aber dann stellt sich heraus, dass das Jahr mal mit dem 1. März anfing, der Papst mal ca. 2 Wochen hat ausfallen lassen, es immer wieder Ausgleichssekunden gab, dann kam Sommerzeit dazu, Länder haben die Zeitzonen ganz gewechselt, wann wurden Zeitzonen eigentlich überhaupt eingeführt etc. und schon ist man mitten drin...

Bei juristischen Fristen gilt zumindest bei uns wohl immer Ortszeit. Im BGB scheint sich nichts zu Zeitzonen etc. zu finden. Für einen Flug muss man vermutlich so denken:

Die Berechtigung sollte für den ganzen Flug gültig sein, also an jedem überflogenen Ort nach Ortszeit in der First liegen. Ich würde das etwas vereinfachen und es so programmieren, dass für Start und Landung geprüft wird. Den Sonderfall wenn im Flug eine Zeitzonengrenze hin und zurück überflogen wird, kann man vermutlich weg lassen.

Das sind ja immer spannende Fragestellungen hier... in einem Detailgrad, wie es anscheinend nicht mal EASA oder FAA regeln.

Es gilt immer Tagesende bei den Gültigkeiten (soweit waren wir ja schon). Eine Uhrzeit ist nicht geregelt. Meine Meinung: Alle Logik spricht dafür, dass es sich um Local Time handeln muss. Sonst bräuchte man ja auch keine Nachtflugberechtigung, weil ja immer irgendwo auf der Welt die Sonne scheint. Ich kann mir nicht vorstellen, dass man sich beim Ramp Check auf den australischen Sunset beziehen dürfte ;-)