"Total Time" and "Total Flight Time"

I have a confession to make.  I use the term "Total Time" liberally throughout MyFlightbook for the "bottom-line" time of a flight entry.  The problem is, that phrase is not really defined, and could be used by a given pilot to refer to either Pilot Time or Total Flight Time.

These are not quite the same thing.  Per 61.51(j), (in the US at least), Flight Time is in "an aircraft".  No training devices are listed here.  Pilot Time, on the other hand, is what contributes to total aeronautical experience (per 61.1(b)), and it is a superset of Flight Time and appropriate Sim time.

That is to say, if you have 100 hours in an actual flying machine aircraft, 20 hours in a certified level-D full-motion simulator, and 30 hours playing Microsoft Flight Simulator, then you properly have a Total Flight Time of 100 hours, and a total Pilot Time of 120 hours.

When MyFlightbook reports a "Total Time", it is a straight-line sum of that field (constrained by any search criteria you specify); it is not distinguishing sim time from real aircraft; it's not even excluding any time you logged there in uncertified sims like Microsoft Flight Sim.  (MyFlightbook does, however, separate these all out in the 8710 form) So if you log time in a sim in the "Total Time" field, you are adding to your Pilot Time, not to your Flight Time.

As I mentioned in a previous post regarding sims, my best advice here is to leave the "Total Time" field blank when not recording time in an actual flying machine; instead, put any sim time into the "Ground Sim" field (or ground instruction into the "Ground Instruction" property, using any aircraft you like).

So if it's a bad idea, then why do I allow people to put time into the "Total Time" field for sims?  Three reasons:

• Some pilots are using this to count Pilot Time.  
• Under other non-FAA regulatory environments, it can sometimes be counted towards flight time.
• Many pilots do catch-up flights to carry-forward time from paper or other logbooks; as this would be a mix of sim and actual aircraft time, I allow people to mix these.

But there's a third reason people will log this: credit towards aeronautical experience.  For example, a requirement for an ATP rating (61.159) in the US is 1,500 hours of aeronautical experience.  But 61.159(a)(6) allows up to 100 hours of this 1,500 hours to be acquired in an appropriate training device, so many pilots view this as allowing them to "count" up to 100 hours in sims towards their total time.


If you do this, then you are following the "Pilot Time" rule - that's OK, but if someone asks you for your total Flight Time, you need to back out your sim time.

I think, however, that the "correct" (can I use "correct" and "I think" in the same sentence?  Sure, I'll allow it...) way to interpret the aeronautical experience requirement in 61.159 here is "The sum of your Flight Time and MIN(100, time in an FTD or FFS under appropriate rules) is at least 1,500 hours". 

MyFlightbook does know about this substitution and applies it to FTDs and FFSs (under the assumption that you're doing it under a part 121/135/141/142 training course) when reporting your progress towards the ATP rating, so it is not necessary to explicitly add total time for these sim sessions in order to receive credit.  And, in fact, to avoid double-counting, a given flight actually credits MAX(Ground Sim, Total Time), in case you logged both.

So I'll repeat my advice: to keep things clean, only log "Total Time" for flights that are in an actual aircraft.

Local time

What time is it?  Generally, there are two answers to that question: what time is it where I am, and what time is it in UTC (Zulu).

All times in MyFlightbook are in Zulu (UTC) time, for a pretty obvious reason: it's the only way to do computations.  If you depart at 4PM EST and land at 7PM PST, you're flight was 6 hours long, not 3, after all; as with all math, you need to use common units.  And in order to compute things like night flight, one needs to know the position of the sun relative to the horizon at a given latitude/longitude and time - and thus the time needs to also be in a common unit system.

The iOS and Android apps on MyFlightbook have an option to use local time.  When this is selected, all the times are still in UTC.  The only difference is in the display.  So in the example above, if you enter "4PM" while you are in New York (EST = UTC-4), that goes into the database as 8PM UTC (2000Z).  When you land at 7PM in LA (PST=UTC-7), that 7PM goes into the database as 2AM (0200Z) the next day.

What's interesting is that if you go and look at your New York departure time after your landing in LA, it will no longer say 4PM - it will say 1PM.  Why?  Because you're now in LA, and it's displaying the unmodified 2000Z departure time in PST, (2000Z-0700=1300PST).  Note that the underlying time is invariant; only the display has changed.

That works well on the device, which typically always knows its location and its timezone offset.  It also works for times that are either entered in UTC, or which are entered relative to your current time zone offset.

But the key thing is that the local time option always works based on *where you are* *right now*.  I.e., it's not based on the time or location of the flight data, it's based on your time and location as the viewer of that data.

Unfortunately, converting from local time to UTC - especially for other than the "right here, right now" case - is a significantly more complicated problem.

E.g., if you are going through old flights and want to log something that departed ABC at 4PM local and arrived at DEF at 7PM local on Oct 23, 1997, you need to know the timezone offset for ABC and for DEF on those dates, including if/when Daylight Saving time is observed (and, if it is observed, when the cut-over dates are)

This is absolutely a solvable problem, but requires a lot of data and it requires maintenance of that data.  Specifically, it requires:

• A database of geographic boundaries of each time zone, including changes over time.
• A database of daylight saving time rules, including changes in those rules over time.

So to compute, say, total time for a flight with local departure/arrival times specified:

• Look up the latitude/longitude of the departure or arrival airport on the date of departure/arrival
• Find the appropriate time zone based on those coordinates
• Determine whether or not to apply daylight saving time based on the date of flight, taking care of the time of arrival (since a flight can span the typical 2am-local transition to/from daylight saving time)
• Adjust the local times based on the offsets computed above.

MyFlightbook does not do the above conversions.  Why?  Money.  There are services which can do precisely the computations above, but because of the large data set and the maintenance required to keep up with ever changing timezone rules, these are not free.  As a free service, it's dangerous for me to offer functionality that could result in unbounded potential expense.

For this reason, my suggestion is to convert local time to UTC before entering historical flights.