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.
