Friday, March 13, 2020

Flight Checker

This week I launched a "Flight Checker" feature on MyFlightbook.  The purpose of this functionality is to analyze your flights, looking specifically for data issues and failure to follow best practices

By definition, these are not "errors", since the system won't let you save a flight that has errors in the first place.  It turns out, though, that the set of issues that constitute an "error" are actually relatively small.  I've found that over the years that I would add one validity check or another, only to have to pull the check because it turns out that there are valid scenarios for it.

So think of the Flight Checker as providing warnings, not errors.  These are things that you can safely ignore, but that you just might want to address.

You can use the Flight Checker in one of two ways.  There is a "batch mode" that examines the flights already in you logbook; you can get to this by going to Logbook->Check Flights on the website.  There is also a "Check this" button that will check a flight that you are in the process of editing; click the icon in the lower-left of the flight editing screen and it will show any issues.

I am grouping these checks into distinct categories of checks. These are described below.  In batch mode, you can select which checks you want to perform because some may not apply to you, or you may just wish to reduce the noise/clutter associated with too many checks.  When performing a check on a flight that you are editing, all of the default groups are included.

Below lists the current categories of checks that I have, and a description of the checks within each category.  I expect that over time I will be adding to this.

PLEASE LET ME KNOW if you have ideas for additional checks that I can do.

Simulator Issues

There are some best practices associated with logging time in a simulator/training device.  I discuss many of these issues here, here, and here.  In that vein, here are the issues that I am looking for in this category:
  • Logging Ground Simulator time in a real aircraft
  • Logging PIC, SIC, or Total time in a sim
  • Logging actual IMC time or cross-country time in a sim
  • Failure to record the device identifier for the sim.  You may have recorded it in the comments for the flight; I don't really have any way to reliably determine if this is the case, so I'm simply looking for the absence of a "Simulator/Training Device Identifier" property on the flight.

IFR Issues

Here I'm looking for some potential issues around instrument flight:
  • Failure to describe the approaches that you logged.  When you fly approaches, you're supposed to record the approach name and airport.  I am looking for an "Approach Name(s)" property, or I look in the comments for something that looks like an approach description, following the format described here.  E.g., 3-ILS-Y-RWY16R@KPAE means 3 ILS-Y approaches to Runway 16R at Paine Field (KPAE).  (Note that MyFlightbook should already identify and highlight these on the website when found in comments)
  • Logging simulated IFR in a real aircraft without either dual time also logged, a safety pilot named (using the "Safety Pilot Name" property), or an examiner ("Name of Examiner" property) named.
  • Approaches or holding indicated with neither IMC nor Simulated Instrument time indicated.  To count an approach, of course, it's supposed to be performed by reference to instruments.

Airport Issues

In this category of issues, I'm looking at your route of flight and trying to determine if there's anything possibly amiss.
  • Use of "LOCAL" or "LCL" for flights that don't leave an airport area.  Both are unnecessary because you can simply say "ABC" for a flight around the airport ABC; it's obvious that it's local because it's just the one code.  "LCL" is also problematic because it is the IATA code for La Coloma airport in Cuba.
  • Use of an airport code that isn't in the database.  Old codes are generally fine - MyFlightbook is a logbook, not a navigation tool, so I deliberately keep old codes around.  So if your favorite airport ABC is now DEF, that's fine as long as ABC hasn't been re-assigned to another airport.  If you have landed at airports that aren't in the system, I encourage you to add them (Airports->Add/Edit Airports on the website) - the crowd-sourcing helps create a very comprehensive dataset!
  • If an airport code is explicitly a seaport and you're flying an MEL or SEL aircraft, I'll flag that.
  • If an airport code is explicitly a heliport and you're flying an airplane, I'll flag that.
  • I also look at the total distance for the route and the total time of the flight and compute an implied speed.  If the speed is over 500kts for a piston aircraft or 1000kts for a turbine aircraft, I'll flag that.  It could be that you didn't log enough time, but more likely you have a typo in one of your airport codes (or a code has been re-assigned) such that your flight from New York to Boston had a detour in New Delhi or something like that.

Cross-Country (XC) Issues

Uggh.  Cross-country time is a mess, as described here, so here are some things I look for:
  • Logged XC time is less than the whole flight.  There are legitimate scenarios for this (which is why it's neither an error nor a checkmark "this flight was XC" option), but most flights are all or nothing.
  • If no XC time is logged but the route of flight is over 25nm for a helicopter or 50nm for an airplane, I'll let you know.  Again, due to the crazy definitions of XC time described in the link above, this could be legitimate.  I use 25 and 50 here because those thresholds apply to pretty much every definition of cross-country time as required for helicopter and airplane ratings, respectively.
  • You can decorate a flight with properties that indicate a given flight was cross-country time less than 25nm, less than 50nm, more than 50nm, or more than 100nm.  If you've used any of these properties, I check that the route of flight's distance is actually consistent with the property that you've used.  I also check for inconsistent/incompatible issues, like recording a different amount of cross-country time from the time listed in the property, or recording time both more than or less than 50nm.

Time Accounting Issues

This category is the simplest check of all: I'm looking to see if it violates this equation:

    Total Time for a flight = PIC + SIC + Dual.

Note that this equation is not true in general in the US; the FAA allows you to log PIC time, for example, even while receiving training, if you are rated for the aircraft (so in that scenario, typically, PIC=Dual=Total); indeed, there are a variety of scenarios where multiple people can simultaneously log PIC time.  But in other jurisdictions, if you are receiving training, then you cannot simultaneously log PIC time because in those jurisdictions only one pilot can ever be the PIC.

For this reason, if I detect that you're in the United States (based on your browser's locale), then I turn this check off by default (you can, of course, turn it on if you'd like).

Logged Time Issues

This category is looking for any time field that is greater than the total time for the flight.  E.g., if you log 1.2 hours of PIC time for a 1.0 hour flight.  This applies to both the main flight fields (PIC, Dual, Night, etc.), but also to any time-based properties that you may have used, with the exception of Ground Instruction Given or Ground Instruction Received.

Also, since total time in a training device should almost always be zero, I don't apply this check to other than real aircraft.

UTC Time Issues

Here I'm looking for consistency in the use of timestamped UTC values, and it breaks down into two sub-categories of issues.

The first subcategories all deal with the time boundaries of a flight, specifically Engine Time, Flight Time, and Block time.  These can have the following issues:
  • Invalid ordering of matching time pairs (block in before block out, engine end before engine start, flight end before flight start)
  • Invalid ordering of related items.  Specifically, [Engine start or block out] must be prior to Flight start, and end of flight must be prior to block in which must be prior to engine end.
  • All of these times must be within 48 hours of the date-of-flight.  I choose 48 hours because the date-of-flight is local time every local date lasts somewhere on the planet for 48 hours.
The second subcategory looks for time issues across multiple flights.  This is mostly important for Part 117 computations, which involve two more matching pairs of UTC times: duty start/end and flight duty start/end.  The difference here from the times in the first subcategory above is that these duty periods can start on one flight end end on another flight.  But I'm also looking for problems with the time boundaries described above.

So here I'm looking for:
  • A flight start, engine start, or block-out time that is prior to the previous flight's flight end, engine end, or block-in time (respectively)
  • A duty period that starts while another duty period is already open (i.e., I haven't encountered the end of the prior duty period).
  • A duty period that starts prior to the end of the previous duty period.
I'm also looking at this flight in relation to preceding flights and looking for inconsistencies between it and the previous flight.  For example, starting a new duty period that is prior to (i.e., overlapping with) the previous flight's duty end, or a block out time that is prior to (overlapping with) the previous flight's block time.

Miscellaneous Issues

This is the category for additional checks that don't fit neatly into any of the above. 

These include:
  • Redundant checkrides. For example, you only ever get your PPL rating once.  If you get your PPL in a C-172, and later add multi-engine privileges in a Seneca, you're not getting a new PPL rating but rather are adding privileges to your existing one.  So you should log this using the "Checkride - New Category/Class/Type" property.  
  • Adjacent flights that appear to be duplicates.  "Adjacent" here means that they sort next to each other (see this post about sorting; it's possible that two otherwise identical flights would have an intermediate flight that would prevent detection.)
  • Unsigned flights that indicate instruction with no Instructor Name
  • Flights that appear to have no data

Friday, March 6, 2020

Early March Updates

I haven't posted updates here in a while, but I have been making updates to the site. Mostly small changes, but one big one that I'm releasing in "Beta" form, which means you'll need to type in a specific URL to get it.

The big one: today I've launched, in beta, a "flight checker." It's in beta, so you need to type in URL's directly to use this.

If you go to, you can scan your logbook for common issues that are not errors per se, but are either minor consistency issues, failures to follow best practices, or other minor things. These are grouped into categories (simulator issues, IFR issues, time issues, airport/route issues, etc.) but can help with "debugging" your data and ensuring that i's are dotted and t's are crossed.

You can also use this to check a flight in real-time before entering it - add "lint=1" to the URL of the new flight page (either "?lint=1" if there isn't already a "?" in the URL, or "&lint=1" if there is) and you'll see a green checkmark in the lower right corner that you can click to see any potential issues in the flight before you submit it.  E.g., if you go to'll see this:

If you click the checkmark, it will give you immediate feedback on the flight you're trying to enter.

Please give me feedback on this.  I'm particularly interested in the following:
  • Are there bugs in my checks?
  • Are there checks I should be doing but am not doing?
  • Are there checks that I'm doing but which are actually valid and should have a way to turn off?

The small stuff:
  • SFAR 73 now (should) properly use a 1- or 2-year flight review computation based on your flying experience.
  • You can now add a flight directly to your pending flights (e.g., if you want to finish it later, or if it's a planned flight that you haven't yet flown). This is in the drop-menu next to the "Add Flight" button:
  • If you have multiple criteria in a search, there's a "clear all" criteria to remove all of the criteria with a single click
  • In the raw data report for flight analysis, I now strip out any column that has all zero values, reducing clutter for flying that you've never done.
  • If you search for flights that contain a true/false property (e.g., "Charity Flight"), the resulting totals should now include an item telling you how many flights had the property. (This had previously been missing because you can't exactly sum up true/false properties).

Thursday, January 30, 2020

Simulated Instrument and Ground Simulator

I've been getting a few questions lately that were the result of confusion between the logging of "simulated instrument" time and "ground simulator" time.  Despite the fact that both of these have a form of "simulate" in their name, they are distinct (albeit overlapping) concepts.

  • IMC (instrument meteorological conditions) is the time you spend in weather that precludes the ability to use visual references.  This can only be experienced in an actual flying aircraft - you CANNOT experience IMC in a training device.
  • Simulated Instrument is the time you spend where you must rely on your instruments for safe flight, other than when you are in actual IMC in an aircraft.  This can be either in an actual flying aircraft - in which case you are using a view limiting device (like a hood) or it can be in a training device ("simulator") such as an ATD, FTD, or Full Flight Simulator when the training device is emulating IMC.
  • Ground Simulator time is the time you spend in a training device, whether or not it is emulating IMC.

Visually, you can think about this as follows:

So what does this mean for logging your time?  Here are a few samples:
1 hour of flight in a C-172, half of which was in the clouds 0.5001.0
1 hour of flight in a C-172, half of which was with a hood (and, presumably, a safety pilot or instructor)00.501.0
1 hour in a multi-engine FTD; half an hour spent practicing single-engine procedures and half an hour spent doing approaches with the screen emulating instrument conditions (i.e., pure white/gray)00.51.00

Note, by the way, that the "Total Time" field for the FTD flight above is 0.  See my prior entry about logging time in training devices for some more tips here.

For purposes of progress towards ratings, such as 61.65 (Instrument Rating), the MyFlightbook will credit simulated instrument time in an ATD, FTD, or FFS towards the required minimum amount of "instrument" time that is required (e.g., 61.65(d)(2) for airplanes requires 40 hours), up to the limit of 20 hours for an FTD/FFS (per 61.65(h)) or 10 hours for an ATD (per 61.65(i)).  Note that if you are training per part 142, 61.65(h) actually allows up to 30 hours in an FTD/FFS, but MyFlightbook uses the more conservative 20 hour limit.

Wednesday, December 18, 2019

Glass panels and Technically Advanced Airplanes (TAA)

People often want to track their time in aircraft with advanced avionics - often referred to as "glass" or "technically advanced airplanes" - for insurance, professional, or personal reasons.  In this post, I'll discuss MyFlightbook's support for this.

Like other aircraft-related attributes (complex, tailwheel, multi-engine, etc.), glass is an attribute of the aircraft used for a flight, and thus not something that you should ever need to log.  If you log time in an aircraft with a glass panel, then MyFlightbook will recognize that fact and allow you to search on it, providing a quick way to get totals in glass aircraft.

I should step back for a moment and point out that "glass" has never (to my knowledge) been formally defined, but "TAA" has; see my earlier blog post on TAA for more information about this.  Note that TAA is a strict subset of glass: all TAA aircraft MUST be glass (since it requires having a PFD and an MFD), but not all glass aircraft are TAA (e.g., a C-172 with a G1000 might not have an autopilot and thus would not be TAA)

Anyhow, most aircraft attributes that matter for logbooks are tracked at the model level because they are (essentially) immutable characteristics of that model, shared by every aircraft of that model.  E.g., a Boeing 737 is a multi-engine turbine aircraft, always; there are no piston versions, no fixed-gear 737's, and no single-engine versions (let's hope; that indicates an emergency).

Glass and TAA, however, are mutable.  I.e., going from steam to glass/TAA - or going from glass to TAA - is not an unusual transition.  For this reason, I need to have a hierarchy of capabilities, starting with the model and looking at the aircraft as needed.

To determine if an aircraft is glass or TAA, I use the following criteria:
  • If the model of the aircraft is flagged as being TAA, this means that every aircraft that has ever come off of the line is TAA, and therefore the aircraft MUST be TAA.  These aircraft cannot be upgraded on the Glass/TAA dimension.
  • If the model of the aircraft is flagged as being glass (every aircraft coming off the line has glass, but may not meet the TAA definition), then the aircraft is glass, but to determine TAA, I have to look at the aircraft itself.  These aircraft may be upgraded from glass to TAA, but obviously cannot be upgraded to glass since glass is the base configuration.
  • If the model may come from the factory in various configs, then I have to look at the individual aircraft.  For example, a C-172 S may or may not have steam gauges.  (Note: I'm not sure anybody is still buying a C-172 S with steam gauges any more, but the point is that if you tell me an aircraft is a C-172 S, I can't say with certainty if it has glass).  An aircraft of this model can be upgraded from steam to glass, or to TAA.
You can indicate whether a model is strictly glass or TAA by editing the model.  You can indicate that an aircraft has been upgraded by editing the aircraft.  In some models, the glass-only option has become so ubiquitous that it's become its own model on MyFlightbook.  E.g., there is in fact a "C-172 S/G-1000" model which is very specifically a factory-installed G-1000 version of the Skyhawk.  This is (not surprisingly) flagged as "glass only", whereas the vanilla "C-172 S" is not.

But upgrading an aircraft raises an interesting question: how to distinguish flights in the aircraft prior to the upgrade from flights after the upgrade?  When indicating an upgrade on MyFlightbook, you can optionally specify a date for the upgrade.  Flights before the upgrade will be treated as non-glass, and flights after the upgrade will be treated as glass/TAA (depending on the level of upgrade).  And if you ordered your specific aircraft with factory glass, just leave the date of upgrade blank; that will cause all flights in that aircraft to be treated as glass/TAA.

TAA time is now an option for FAA Commercial ratings in lieu of a complex aircraft; MyFlightbook can determine TAA time towards this rating based on the criteria described above.

Some people also wish to distinguish the kind of avionics that an aircraft has. I choose not to explicitly support the type of avionics because there are an unbounded numbers of possible configurations, with new ones introduced all the time.

So for this, I generally suggest making up tags like “#G1000#” or “#ENTEGRA#” and putting them into the private notes of your aircraft.  You can then search for “#G1000#” and the result would be all of your time in aircraft that are tagged #G1000#.  (Note that there’s nothing magical about the “#” prefix/suffix; I just suggest it as a convention because it avoids false positives when searching).  So if you want to see all of your glass time with G-1000 avionics, you could search for "#G1000#" and the resulting totals will reflect your G-1000 time.

Tuesday, December 3, 2019

User Created Airports

If you've created airports on MyFlightbook, well, first, "thank-you" - you're helping MyFlightbook have a very thorough (and living!) airport database!

But you may notice a few changes regarding your airports recently (early December 2019).
I've finally gone in and built a tool that lets me review user-created airports that might be duplicates of existing airports. It's always a challenge as airports are closed, new airports are opened (or assigned re-used codes), or airports move from one location to another. But I also want to avoid things like "JFKIA" (an airport somebody created to be "JFK International Airport") being coincident with KJFK and getting picked up as the nearest airport by the GPS.

So I've built a tool that lets me review all user-created airports (or seaports/heliports) that might be coincident with an existing airport (seaport/heliport) and decide what to do. I have several (not-mutually-exclusive) choices in these cases:
  • If both the new and the existing airport are legitimate (E.g., "EGLL" and "LHR" are ICAO and IATA, respectively, for London Heathrow), then I will actually "absorb" the airport. I.e., I will remove your name as the creator of the airport, and it will be treated as a native airport. It will no longer show up as one of your airports.  Thank-you for your contribution!!!
  • I will typically mark one of the two codes (usually the 4-letter ICAO code), in the above scenario, as being "preferred". That way, if you're somewhere at the airport and use the app to read the closest airport, it will be equally close to multiple codes; this allows me to bias towards the code that is least likely to have ambiguity (which is why it's typically ICAO). Or, if one of the codes is an obsolete code, it can use the newer code.
  • I can also coalesce the precise latitude/longitude between the two airports, so that multiple codes are equally close.  This helps to avoid the mobile apps picking up EGLL on one side of Heathrow airport and LHR on the other.
  • d) Finally - and this is relatively rare, but I've done it with a few dozen airports - I can delete your airports. Usually this is due to a typo (e.g., I've seen codes that mix up a capital-O with a zero), but it can also be due to a made-up code when there is a legitimate ICAO/IATA code that applies. If I delete your airport, the tool will automatically map any flights that use the old code to instead use the new code. This doesn't violate any signed flights (route is excluded from the change detection), but it obviously does mean some minor changes to your logbook.
The mobile apps can't update their airport databases over the net; instead, every few months when I'm updating the mobile apps I'll update the airport database as well, so it can take a few months before these changes will show on the mobile apps. But all of the changes are live on the website today (and ongoing).

Thursday, November 7, 2019

Local Time part II

In an earlier blog post, I discussed the challenges of supporting local times on the MyFlightbook website. 

The short summary of the problem is that it's critical that all underlying times be UTC, in order to enable any math or computation determining length of flight or duty periods or similar.  The blog post described why I don't support import/export using anything other than UTC, and why I don't store local times in the database.

However, it is possible to provide support for data entry and editing in a local time zone, just as the mobile apps do.  The idea (as the mobile apps do) is that you convert any UTC time to local time when putting it into an editable field, and then convert back to UTC when committing the edit (i.e., when saving or updating the flight). 

iOS and Android always know their current offset from UTC - i.e., the offset at the time and place where you are making the edit.  This is fine, as the iOS and Android apps are generally optimized for data entry in-the-moment (e.g., during or shortly after your flight) rather than bulk entry of historical flights.

Web browsers, sadly do not provide time zone information.  I can get the current offset from UTC for the user's browser (and only after the first request - too late for the first page that is requested!), but I cannot get a name for the timezone (thus enabling, for example, "EDT" for "Eastern Daylight Time"), nor any rules around daylight saving time

But all is not lost, and today I released a new feature that allows you, if you like, to declare a preferred time zone.  (Go to Profile->Preferences->Flight Entry).  This applies on the web only, and will allow you to enter/edit times in the specified time zone.

If you enable anything other than "UTC", then all of the time fields that usually have a "UTC" label or description will change to say "Custom TZ"; you can hover over this to see which time zone is in use; doing this will show you the standard offset from UTC, even if you are in daylight time, but any conversion should correctly account for standard/daylight time. 

As an aside: I use "Custom" rather than "Local" because "Local" is inherently ambiguous: e.g., if you live in Chicago, but you have a flight from LA to New York, is the "local time" Pacific, Central, or East Coast?  "Custom" here at least clarifies that it's one you've specified.  Why not use a 3-letter acronym like "EDT"?  Two reasons: (a) the acronyms don't span daylight/standard time.  E.g., EDT is specifically daylight time, but in August you probably would want EST, so you'd have to use the more ambiguous "ET" and (b) more practically, the system doesn't provide a set of acronyms for the ~139 timezones in the system.

There's actually an additional benefit here that goes one better than the iOS/Android apps: by specifying a timezone, the daylight time rules are encapsulated.  So if it is August 8 and I'm transcribing a flight from February that was at 1pm Pacific time, that will be correctly converted to 9PM UTC (Pacific Time in February is Pacific Standard Time, which is UTC-8) but a similar flight from May would be 8PM UTC. 

I am only doing this for editing times; I am still sticking with UTC for all display purposes, such as printing or displaying details of a flight in the logbook list.  Not only does it avoid ambiguity to do so, but it also removes the need to display the timezone (and as mentioned above, the system doesn't provide me with a short abbreviation for the time zone names, so it would literally have to display something horrendously long like "Pacific Time (US & Canada)" (i.e., the name of the timezone) next to each time.

Sunday, October 6, 2019

"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.

Thursday, October 3, 2019

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.

Monday, September 2, 2019

EASA currency and license revalidation

I did some updates over the past few days to better support EASA currency rules.

For a while, I've supported EASA LAPL (FCL.140) rules, which can be turned on in preferences on the website. 

If you turn this option on, I also default to EASA PPL rules where appropriate rather than FAA rules for regular passenger currency.  The EASA PPL rules (FCL.060) for carrying passengers are basically the same as the FAA rules (3 takeoffs+landings within 90 days), but they differ for night:
  • Whereas FAA rules require 3 takeoffs and landings to a full-stop between 1 hour after sunset and 1 hour before sunrise, the EASA rules require only one takeoff/landing, and it doesn't have to be to a full stop.
  • If you have an instrument rating, EASA imposes no particular night requirement.
The way that I've implemented this is that I look for a night takeoff and either a full-stop night night landing or a night touch-and-go landing within the past 90 days.  But if I see any evidence that you have an instrument rating, such as an instrument checkride, an IPC, or one of a few other things that qualify as an IPC, then I don't bother reporting night currency because it is then identical to (and thus redundant with) your regular FCL.060 passenger-carrying currency.

Note that I said "if you hold an instrument rating", not "if you have a valid instrument rating", or "if you have an instrument rating for the category or class".  The regulation is worded thusly:

(b) Aeroplanes, helicopters, powered-lift, airships and sailplanes. A pilot shall not operate an aircraft in commercial air transport or carrying passengers:
(1) …; and
(2) as PIC at night unless he/she:
(i) has carried out in the preceding 90 days at least 1 take-off, approach and landing at night as a pilot flying in an aircraft of the same type or class or an FFS representing that type or class; or
(ii) holds an IR;
(b)(2)(ii) above simply says "holds an IR", with no other qualifier, so I am treating that as being unqualified.

Another key difference in EASA land vs. FAA rules is that FAA ratings don't expire, but EASA ratings do need to be re-validated periodically.  This is like the FAA requirement to have a flight review.  But EASA adds a wrinkle to this: you need to do the validation within the 3 calendar months prior to the expiration of your rating. 

So, for example: suppose your rating expires Sept 30 2019 and is good for a year.  If you did your validation flight on July 15, 2019, then your rating is now good until Sept 30 2020; in effect, you can have as long as 15 calendar months as a result.  But if you did your validation flight on May 15, 2019, then your rating is now extended only until May 31 2020.

As a result, it is impossible to predict when a validation is required without knowing when your rating expires, which means that there is no way to escape having you enter those expiration dates somewhere.  And since the number of possible ratings is unbounded (due to type ratings), I can't enumerate the set of due dates that you need.

So here is my recommendation for dealing with re-validation of EASA ratings:
  • For each rating that you hold that requires re-validation, create a custom deadline (Profile->Preferences->Deadlines) that reflects the date by which the validation is due.  This will then show up in your currency.  Set it up to automatically extend by 12 or 24 calendar months, as appropriate.
  • When you do the re-validation, update the deadline to reflect the new date.  This will allow you to handle the 3 month window for performing the validation.
  • If you like, you can also set up a custom currency rule that looks for a flight review or IPC (to indicate revalidation) in an appropriate set of category, class, or model.  This will use a date extending by 12/24 calendar months, where you might actually be entitled to more, but at least this will give you a conservative date.
  • Note that re-validation of simple SEP ratings can be accomplished essentially by remaining current via LAPL rules, so you can track that simply by tracking your LAPL currency.