Deadline Improvements for Aircraft

 Right now, you can create a custom deadline and tie it to an aircraft using hours rather than a date.  E.g., “Inspect Brake Pads at 200 hours.”  That would show up in your currency as a black unitless number:

It's black because while I can use the passage of time to gauge how close (or beyond!) you are getting to a date-based deadline, I have no such way to estimate how close the aircraft is getting to an hours-based deadline.  Further, since the hours are unitless, I don't know whether they are hobbs or tach based.

Today, I've I made two changes.

The first is to make hour-based deadlines more sensitive to an estimate of where you are relative to the deadline.  

Deadlines that are tied to an aircraft and which are hours based rather than date based will now find a high-water-mark ending hobbs and/or tach for your flights in that aircraft.  They will figure out which one that exists and is closest to the target.  The idea being that if your tach is, say, at 1,385 but your hobbs is at 4,801, and you set a deadline for 4,800, you probably meant hobbs and not tach.  

The deadline then uses that value (if found) to do green/blue/red like other currency/deadline items.  I’m using red for overdue, blue for getting close (within 10 hours) and green for anything that is more than 10 hours away.  And I show my estimate of where the aircraft currently is:

Of course this is only an estimate: if you share the aircraft and someone else has flown it, or if you neglected to log an updated ending hobbs on your last flight, then the true value is certainly higher.  But it should be a pretty decent estimate, especially if it’s your plane and you are good about reliably logging this.  (Note: if you use the club functionality, you can scan across club user’s flights to find a likely better high water mark).

The second change is to apply this to oil changes, the hours-based deadline for aircraft that is so common that it's built-in to MyFlightbook. 

When you enter the hours that the last oil change was performed, I had been showing that value plus various time intervals to suggest when you might need to next change it.

But I decided that with the enhancement above to deadlines, the simplest way to do this is a custom deadline, and with the enhancement above, it’s easy to add that:

If you click on “Add a deadline using an interval of:”, then it creates the new deadline, associated with the aircraft (and with the default regeneration interval that you selected (in the example image above, it was set for 275 since the last oil change was at 250):

Due to the deadlines enhancement, it will show green/blue/red based on the estimate of airframe hours:

The nice thing about doing it this way is that you can track any AD or similar periodic task in the same manner. 

Visited Airport Colored Map

Today's fun new feature is a colored visited-airport map.  I'm calling it "Beta" for a few reasons I'll discuss below, but it works pretty well.

The idea is to color in countries* and (a limited number of) states/provinces in which you have recorded flights.

Here's mine:

This, of course, looks very similar to the Visited Airport map I've had for a long time that is based on Google Maps:

The Google Maps is nice because it's highly interactive, but I haven't found a way in Google Maps to do the one feature I thought would be cool, which is coloring in the countries and states you've visited.  So I found a free library that works pretty well and I decided to have some fun trying to integrate it; the result is above.

To try it out, go to Airports->Visited Airports->Countries/Regions and click "View a colored map of visited countries/regions/sub-regions (BETA)" to view your map.  This link is sensitive to any query you've done on the Visited Airports page, so if you change your search criteria there, it will change in the map as well.

The colored map has some fun features:

• You can turn the airport icons on/off (check/uncheck the "Facility" checkbox)
• You can drag the map around and zoom it
• You can see new places you visited by year (look in the right-hand bar) and even animate your visits over time using the play/pause bar on the bottom of the screen.
• You can hover over a top-level region to see its details, and click on it to view the airports in that top-level region.
• Click on an airport icon to view the name of the airport and the year you first visited it.
• In the upper left corner, you can see the number of top-level regions, subregions (states/provinces/etc.), and airports.  Click on these to see details.

But it also has a few limitations.  

One is that the map it's based on is only coded with some states/provinces/subregions, so for now at least it will color in countries and then will add a darker color for states/provinces in the US, Canada, Australia, South Africa, Brazil, and Germany.  That's probably OK, since outside of these countries, most of MyFlightbook's sub-regions are small - more akin to counties, which only have a few airports each, so the coloring is less interesting.  

Another limitation is that while you can zoom and drag the image around, you can't "rotate" the global projection to put your particular region in a central top-down view. 

The code I am integrating also assumes a full document window, and I haven't done the engineering to put it into a "MyFlightbook" skin, so I'm opening this into a new window/tab so that you don't lose where you were in MyFlightbook.

Let me know what you think!

*As I disclaim on the Visited Airports page, I'm distinguishing "countries" from "nations."  This is meant to be a fun feature, and I am not making any statement about political divisions, only major geographic regions. E.g., Greenland is a territory of Denmark, but is treated as a top-level region in this taxonomy.

What time is it?

 Time is an interesting thing.  I won't even get into all of the weirdness that happens when you travel close to the speed of light that mean that time itself is inherently bound up with the question of who the observer is of that time.  Even in aviation, time is a messy concept.

In the world of MyFlightbook, there are at least 5 possible interpretations of a given time.

Specifically, if I say something happened at 3:00pm, that could mean any of the following:

1. 1500Z, I.e., UTC time.  
2. 3pm, but I've specified that my preferred time zone is Pacific Time, so in July that means 2200Z but in February that means 2300Z.
3. 3pm "local" time (where you are).  E.g., I am in Seattle as I write this, and it is July so Seattle is currently 7 hours behind UTC, so this corresponds to 2200Z, but 3pm "local" in New York in July is only 4 hours behind UTC so corresponds to 1900Z.  It's actually worse than that, though: given shifting daylight time boundaries, "3pm local" even in a known location like Seattle might be 2200Z or 2300Z, depending on the time of year and which year it is!  
4. 3pm PDT (or "1500Z-0700").  This is more specific than "local" time because PDT is defined as 7 hours behind UTC, regardless of time of year.  (In the winter, Seattle is PST - which is 8 hours behind UTC - but alas PST is not the same as PDT)
5. 3pm.  Is that local?  PDT?  UTC?  You simply can't tell from the information provided.

You can see why aviation uses Zulu time.  If you don't use UTC, then a 2-hour duration jet flight between Boston and Chicago is 1 hour when going west and 3 hours when going east!!  And indeed, I can make a stronger statement: you can't do math if the times aren't in UTC.  As this Boston/Chicago example shows, the math only works if you are in a single time zone, and other calculations (namely night flight) go one step further and only work if the time is in UTC.  Anything else breaks things and renders any mathematical computation useless.

So for the vast majority of cases most things, MyFlightbook uses UTC (option 1 above).  If you tap "Tap for Now" on a time field in the MyFlightbook app, or put in a block in/out time or engine start/end time or similar, you are specifying a UTC time.  Under the covers, these are ALL stored in UTC.

Scenario #2 above involves a "preferred" time zone. On the website, there is an option (Profile->Preferences->Flight Entry and Display) where you can choose a preferred time zone (the 2nd option above, see image below).  If you choose this option, then all times are converted FROM UTC to the specified time zone (accounting for daylight saving) for display, and when you enter a time, they are converted from that time zone back TO UTC.

Note that this doesn't change based on your location.  If you set this and then travel to London, your times will still display in Pacific time even though you're not currently in Pacific time.  

It is super important to note that even if you have a preferred time zone, the underlying times are still all stored and processed in UTC!  I.e., it is simply a conversion applied for display and data entry purposes.

On the mobile apps (iOS/Android), you have an option to use local time (scenario #3 above).  "Local" in this scenario is the third bullet point above, and functions very much like the preferred time zone that I just described, except that the "preferred" time zone is reset as your phone/tablet travels from timezone to timezone. 

E.g., in the Boston/Chicago example above, suppose that it is July and I depart Boston at 10am local time (EDT) with the "use local time" option selected.  If I tap "Tap for now" on block-out, the system sets the block-out time to the current Zulu time of 1400Z (=10:00am local + 4 hours to UTC), but it displays that time converted to EDT as (1400 - 0400 =) 10:00am EDT - i.e., the local "Now".  

Now I fly 2 hours to Chicago and land.  It is now 1600Z - two hours later - but Chicago in the summer is 5 hours behind UTC, so when I tap "Tap for now" on block-in, the system sets the time to the current value of 1600Z, but it displays it as (1600 - 0500 =) 11:00am CDT, i.e., the local Now.  And if I look at the block-out time - which had said 10am when I left Boston - it now says 9:00am because we are now in Central Daylight time.  Of course, this is still the same 1400Z (9am = 1400 minus 5 hours) block-out time, just expressed in the new time zone.

As with preferred times zones, once again ALL times remain UTC under the covers; it is only the display (for both reading and entry) that changes!

So the subtle difference between these two examples is that "preferred time zone" is just that: an expression of my preference, which only changes if I explicitly change it.  Whereas "local" time can change simply by moving between time zones, with no explicit action on my part.

Most times on MyFlightbook can be handled in that manner, but there are a few cases where scenarios #4 and 5 rear their heads.

The mobile apps actually are guilty (?) of using scenario #4 when recording flight track data.  They capture the local time - so that you can view things in a time zone that makes sense for where you were when you flew the flight (which may not match either your preferred time zone of scenario #2 above, nor be your current time zone as in scenario #3 above).  They do this by capturing the local time in one column of the CSV track data, and including a second column ("TZOFFSET") which contains the number of minutes to add to the captured time in order to reliably compute a UTC time.  This works fine - "1500Z" with a 420 minute (7 hour) offset in Seattle can quite accurately compute a 2200Z UTC time, but still capture both the fact that the GPS sample in question was at 2200Z and at 3pm local.  And for this reason, when graphing, MyFlightbook does compute a UTC column that you can graph, but the default time stamps are the local time where you were when the sample was captured for ease of viewing.  Note, of course, that if you cross a time zone boundary, this means that the "date" data could repeat (since you are reliving an hour of local time), but the utc-date cannot repeat.

And...then there is scenario #5 above: a naked date with no clue about its time zone.  Is it a UTC time?  EDT?  PDT?  You simply can't tell; it is inherently ambiguous.  The biggest source of this problem is in user-supplied data, and the most common example of this is when users import flights using naked local times, and that's mostly from airline pilots uploading their schedules.  It's generally not a problem unless they check the box for MyFlightbook to compute things like night flight on their flights, and then everything falls apart.

Sadly, converting from local time to UTC is non-deterministic.  By definition, there are local times that either don't exist in UTC (2:30am on the day you "spring forward") or that exist twice in local time (2:30am on the day you "fall back").  Harder still is that the definition of who observes daylight time and on what schedule is not exactly static.  There are services that can take a latitude/longitude/date/time and return the UTC time, but they cost money (I'm a free service) and there is inherently latency involved with sending off a request and getting an  answer, so I have made the explicit decision not to use them.  As a result, naked dates are just...well, they're just pretty useless.

Finally, there is one place where the date-of-flight is actually impacted by your local time!  Europeans may not encounter this much, but Americans often will.  Although I'm not aware of any official guidance here from either the FAA, EASA or other agencies, the date you use for the date of flight seems to always be in local time.  But, for example, EASA specifies explicitly that the time of departure and time of arrival should be in UTC.

So in Europe, if I depart Amsterdam at 6pm and arrive Frankfurt at 7am on July 10 (when they are UTC+2), I could put July 10 as the date of flight, and use 2000 and 2100 as the departure/arrival times.

But now take that same example and move it to be LA to San Francisco.  I depart on July 10 at 6pm - which is July 11 0100Z! - and arrive on July 10 at 7pm, which is July 11 0300Z!

For this reason, there is a rather esoteric option in Profile->Preferences where you can say whether the "date of flight" field represents a UTC date or a local date:

This is primarily used to determine whether a simple time is shown for departure/arrival ("21:00" arrival in Frankfurt) or whether the time needs to be further qualified by a date ("July 11 2023 03:00") because it is distinct from the date-of-flight.