Flight without engine\flight start time, will show up chronologically after a flight with these times, even if the ID value is higher

[zartom]

is it intentional?

[ericberman]

https://myflightbook.com/logbook/Public/FAQ.aspx?q=57#57 describes the sort order. So, yeah, if you're comparing something without any other distinguishing value, it's undefined. ID value is only used if I am comparing like values (e.g., flight start to flight start, engine start to engine start) and have equality (or both are undefined/empty) all the way down the priority chain.

E.g., suppose I have flight A and B. When sorting, I compare A to B (well, the database does) and compares them in the following manner:

• If A's date doesn't equal B's date, then the date determines their order. OTHERWISE
• If A's flight start doesn't equal B's flight start, then flight start determines their order. OTHERWISE
• If A's engine start doesn't equal B's engine start, then engine start determines their order. OTHERWISE
• ...

Note that this means that if you specify a flight start (but no engine start) for one flight and an earlier engine start (but no flight start) for another, this too could unexpected results because I'll compare flight start, get an inequality and I'm done with the sort - never even look at the engine time.

So yes, this is by design. If you want to control within-day ordering of flights, provide a common value for each of the flights (flight start, engine start, hobbs, block-out - doesn't matter, just make sure that each of the flights has a value for the same sort criteria.

[zartom]

I understand. According to the algorithm you described, you say "doesn't equal" but like you say it's undefined. Why not add a fourth line to that procedure, that compares flight ID's, only if a certain has neither of the flight start or engine start data and can't yield a sorting output (other than comparing dates)? this way, it won't change anything EXCEPT when comparing flights with no times input (like those that I am dealing with now, adding those I didn't record in real-time, one by one, retroactively)

In my case, if I have partial data, I'd have to remove the actual times recorded in the other flights so the ID comparison will take priority, rather than invent flight or engine times that I do not actually know

[ericberman]

If flight A has a flight start, Flight B does not, then by definition these two flight start times are not equal - that much is defined.

The real question you're asking here is "How does null (empty) compare to a defined value - does it go ahead or behind the other?" In this case, null is less than any defined value, so that's how they sort. I.e., a flight with an empty flight start is treated as happening before a flight with a defined flight start. It's deterministic.

Mixing and matching sort criteria (e.g., comparing, say, a flight start with an engine start) leads to all sorts of ambiguities and craziness. I suppose one could sort on EARLIEST(Flight start, Engine Start, Block Out), but even then - what if all of those are undefined for flight A but flight A has a hobbs time, and flight B has a Flight Start but no hobbs time? How do you compare those apples and oranges? (Never mind also this extra computation would also slow down one of the most frequent database queries)

ID comparison is a "last resort" that assumes you entered the flights in chronological order; it's a terrible fallback, but it's...something.

If you have partial data, then I'd suggest guessing the start value for the flights that don't have one - or just pick one. E.g., if you have flight A that was a 14:00 and flight C that was at 16:00 and you don't have a start time for flight B, just pick 15:00 (or even 14:01) to put it in the middle. No harm in an estimate of start time - especially if you don't add a guessed end-time (and thus do not accrue any elapsed flight/engine time for that flight)

[zartom]

I am circling back to this issue as I reencountered it recently:

I read again the sorting steps you take and the assumptions regarding null value. I have two flights with engine times for both. However, only one has flight time - so that one is sorted earlier, even though it happened later (by engine times and flight ID). so the question here is actually why Flight Time takes priority over Engine Time? We all start the engine before we take flight, so why not have it earlier? what happens if you taxi to takeoff, realize you have an issue, and taxi back to the parking spot? And then later when you fix the issue and go on flying, that second (successful) flight will be sorted earlier than the first because it has the Flight Time entries even when the first one is loggable according to CFRs because it was taxiing under own power.

The scenario behind all this is that the vital time here in my case (for logging time in my certain operation and also for payment) is engine time/total time/block time - all these can be input manually from the employer's database systems. Flight Time for me, however, is only there if I remember to use the GPS tracking by starting the flight before takeoff... which doesn't happen all the time.

[ericberman]

Hmmm...what you say makes sense. I'm not quite sure why I did flight time over engine time, but you're right - the priority should be block THEN engine THEN flight THEN hobbs. I'll do that.

[zartom]

Will work on mobile devices as well?

[ericberman]

Ought to; they don't do their own sorting.