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:
- 1500Z, I.e., UTC time.
- 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.
- 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!
- 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)
- 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:
No comments:
Post a Comment