• Apple released it's annual update - iOS 17 for both iPhones and iPads. After preliminary testing we see no issues with both Logbook Pro and APDL on iOS 17. We will continue our thorough testing with the public release and follow up should we find any issues.

    We are giving a green light on iOS 17 for all of our iOS apps.

Time Zone Design Confusion


Well-known member
May 24, 2004
Peralta, NM, Earth
Neal suggested I post this idea, so it's his fault. /Forums/emoticons/smile.gif

I've never understood why software designers don't keep the internal time
in UTC *always*, then convert the result to whatever time zone you want
when displaying it and accepting input.

And what do you do during that very confusing time in the fall when
the time goes from midnight to 1am, then back to midnight, then
back to 1am? Or maybe it's between 1am and 2am, whatever.
How do you calculate durations of flights?

And that's not to mention the legislation I just heard about today that
may extend DST for another 3 weeks in the fall and or spring or
something. It's enough to make me want to move to AZ where they
don't participate in that particular idiocy.

Especially in flying where you cross timezones, it gets very confusing.
And what Neal sent out in his newsletter about handling DST was also
very confusing to me, especially when he said something about when
moving to a new timezone, you can't change the timezone of the program.
This is going to cause a big problem if somebody moves, and the only
people who move their permanent address more often than pilots are
people on the lam. /Forums/emoticons/smile.gif You've got to have some way to have the pilot's
home base/timezone in the program be able to be moved from one
timezone to another.

If everything is handled internally as UTC, then the input and display might be
a bit more complex, but at least the time kept internally would be
without confusion.

In fact, now that I think about it, in the logbook display
where you have start-time, end-time, what happens when they're
in different timezones? And what about the poor freight-dog who's
in the air at the time we go from DST to ST in the fall where the
hour repeats (like I mentioned above)? You really need a timezone designator
in the 'block time' entries as well.

When we wrote the software we tried to give the flexibility of your old little red book.

The simplest way to run the software is (as you suggest) to pick a standard timezone. In our software this is the 'Logbook Timezone'. All times are stored in this timezone. So in the simplest form, if you set Logbook Timezone to 'UTC' you are all set. Then on the logpage set your timezone selector to 'Logbook'. Enter all times in ZULU, no conversion necessary.

Most pilots however like to track the times in a more familiar timezone. In this case set Logbook Timezone to 'UTC-5 (for exmaple)' to record all times in EST. When Daylight Savings is in effect (regardless of what dates that actually happens) check 'Daylight Savings is in effect' on the 'Timezone' preference page.

For entering times into the logbook you have four choices based on your 'Timezone Selector' (Logbook, Zulu, Local, Domicile).

For those using ACARS or GPS (Select Zulu, and enter the times). You can switch back to (Local) to see your report time or duty off adjusted to your locale.

If you are using your watch, change the selector to match your watch.

Once you have it setuped and tapped a few times in it should require no mental math.

Fly Safe!

Paul Auman
APDL Development Team
NC Software, Inc.