Default Date of Flight on iOS or Android

(Updated in mid-June 2023; please see the update below)

When using the mobile apps, the "date" field might often be filled in with a stale date - typically the date that you last flew.

So, for example, imagine that you take a flight today (the 23rd as I write this) and after the flight fill in the details of the flight and tap "Add".  The flight gets added to your account and the "New Flight" screen gets reset, including (a) the same aircraft you just used for the flight you just entered, (b) today's date (the 23rd), and (c) some other carry-forward information as appropriate (such as the aforementioned Hobbs time)  Tomorrow (the 24th) you take another flight.  When you tap on "New Flight" it will still say the 23rd because that's the data that was on that screen when you last left it.

I'm occasionally asked why this is and asked to change it so that it always defaults to "Today".  Unfortunately, there's no perfect solution here: optimizing for one scenario actually makes it worse for others, and I've always come back to the same conclusion that it would be the wrong behavior, for two main reasons:

Mostly - it changes data simply based on navigating away and then back to a screen – that’s generally badness, and there’s nothing anywhere else in this system (or any other system I can think of) that modifies data based on a view/navigate event.  For example, imagine if you were to start looking for an airline flight on a given date, then go to another tab to verify you can get the hotel you want, and then when you navigated back to the airline website tab and it had reset your date of flight or origin or destination.  

Think of “New Flight” simply as a browser tab – it’s completely independent of the other tabs, and it doesn’t update its data simply because of the passage of time.  

But perhaps the bigger reason is that it breaks a lot of very common scenarios.  

For example, if you fly today (the 23rd) and fill in some of the data after the flight, but not all of it.  Then tomorrow (the 24th) you fill in the rest of the data, it would be an error to push the date up to the 24th without you doing something.  Or, suppose you depart at 10pm on the 23rd and land after midnight on the 24th - now the date-of-flight would (incorrectly) be the 24th instead of the 23rd.

In a similar vein, it would break the scenario of entering an older flight unless you could complete it without interruption.  For example, suppose you start entering a flight from last week, but you get interrupted and have to leave the screen for a moment.  You come back and continue entering the flight but - alas - now the date has updated from last week to "today."  Not what you intended at all.

So that's why it doesn't update to "today".  But it is obviously not unusual to start a flight on a day that is after your most recent flight.  

For this reason, the apps implement a few "fail-safes" that try to ensure the date is the current (local) date, when appropriate:

• Setting a flight start, engine start, or block-out time will all adjust the date field to be consistent.  So, for example, if I last flew on April 21^st, then the date-of-flight will probably still say April 21.  But if I press “Tap for now” on block out, it will set it to whatever “Now” is locally (April 23, as I write this)
• You can press-and-hold the date field to set it to "today".  
• If you want to clear the form for a new flight, you can always do a “Reset” (tap the action button on the lower toolbar and you’ll see the Reset option), and that sets the date to Today

UPDATE, JUNE 2023

I've updated the iOS and Android apps to have a new notion of "(Today)" as the date.  Think of it as having no specific date at all, and this "floats" with the clock.  If you submit a flight that has "(Today)" (i.e., no specific date), then at that point, it is assigned whatever the current local date is. 

If you tap on the field while it says "(Today)" it will be set to the current date - and since that is a "fixed" (as in "unmoving") date, it will remain there unless or until you explicitly change it or delete it (i.e., render it unspecified/floating again). 

When you reset a flight or when the form is cleared for the next flight after submitting a previous one, the date is set to "Today".

So, for example, if you fly on Monday and fill out a new flight form that has "(Today)" as the date...:

• If you tap on "(Today)", it will set to Monday's date (fixed).  If you wait until Wednesday to add the flight to your logbook, it will be entered with Monday's date.
• If you leave the date as "(Today)" and wait until Wednesday to add the flight to your logbook, the flight will get *Wednesday's* date.
• If you pick any specific date, that date will not change by itself.  But if you delete the date, it will return to a floating "(Today)" value.

The fail-safes described above for the pre-"(Today)" behavior still all work.

Total Approaches and autofill of enumerated approaches

In a previous entry, I describe MyFlightbook's model of logging a total approach count and then optionally describing subsets of those approaches.  The idea is to strike a balance between ease of data entry and ease of computation for things like 61.57(c) instrument currency and totals.

So, for example, if you go up and practice a bunch of approaches, you might do 2 VOR approaches and one ILS approach.  In this scenario, you'd log "3" in the "Approaches" field, and then use the "Approaches - VOR" and "Approaches - ILS" properties to log 2 and 1, respectively.  Putting "3" in the approaches field lets the currency computation for instrument currency know unambiguously that you performed 3 approaches; the remaining properties are really just for your convenience if you like to know how many ILS or VOR approaches you've performed.

Expanding on that last point a bit: it's fine if you simply log "3" in the approaches field and don't bother with any of the subset properties (although 61.51(g)(3)(i) does require that you provide the location and type of each approach; this can be done in an unstructured textual manner in the comments for the flight or in the "Approach Name(s)" property).

There are a whole bunch of possible approach types in the system (ILS, VOR, RNAV, NDB, etc. - 43 different kinds at the moment, actually!) and these are flagged as approaches.  

As a convenience, when you save a flight that has one or more of these approach properties, but that has no total approaches indicated, it assumes that you were not explicitly declaring 2 total approaches but rather that you neglected to fill in that field. For that reason, it adds up the enumerated approaches and auto-fills the Approaches field.

So, for example,

Flight has:	Then:
2 ILS approaches 1 VOR approach Empty "Approaches" field	Approaches field is auto-filled to 2 + 1 = 3
2 ILS approaches 1 VOR approach 5 in the "Approaches" field	Flight is unchanged - clearly stated there were 5 approaches, and you've described 3 of them
2 ILS approaches 1 VOR approach 2 in the "Approaches" field	Error - you've described more approaches than the total that you indicated.

A key observation about this is that the math above only works because the properties that are tagged as approaches are mutually exclusive: a given approach cannot simultaneously be an ILS approach and an NDB approach, so adding the two together is OK.

There are a number of approaches that you can describe with properties, though, that are not flagged as being approaches and thus do not result in the autofill behavior described above.

The first of these is "Approaches - Visual," for the obvious reason that you don't want this to count towards your total approaches because it would mess up your 61.57(c) currency (which requires you to flight by reference to instruments).

The other exception to the autofill rule are approaches that are not mutually exclusive with other approaches.  This includes things like Category I/II/III approaches, RNP approaches, or coupled vs. hand-flown approaches.  These are subsets of the subsets, if you will: think of them as an adjective/modifier/constraint on a procedure, as opposed to a particular type of a procedure.

So, for example, if you fly 3 ILS approaches to a runway, 1 of which was a Category II approach and the others were vanilla ILS approaches, you might log 3 ILS Approaches and 1 Category II approach, but it would be a mistake for the auto-fill feature described above to fill in "4" for the total approach count.

For that reason, these "approaches" are not flagged internally as actually being approaches, and thus will not trigger auto-fill of the approaches field; they're really for your recordkeeping benefit only.