More than many of you want to know
: Wellllll, not really... According to the CFR (Title 14, Part 1.1 definitions) :"Night means the time between the end of evening civil twilight and the beginning of morning civil twilight, as published in the Air Almanac, converted to local time." "Civil Twilight" is the time when the center of the sun's disk is 6.5* below the horizon. So now we grab the Air Almanac - oh wait, it's only available (for US pilots) by purchase from the government. However, one has been posted (unofficially) at :
NavList: A Community Devoted to the Preservation and Practice of Celestial Navigation and Other Methods of Traditional Wayfinding http://fer3.com/arc/m2.aspx/Air-Almanac-2020-full-pdf-now-available-FrankReed-dec-2019-g46422 If you download it, prepare for a headache. It includes a huge amount of data as it provides info for use in celestial nav. However, the pertinent data for pilots can be found way down near the bottom -Pages 871-886 (of 909 pages) where there is a set of tables for sunrise/sunset and Morning/Evening Civil Twilight and by Latitude (@ Sea Level). Oh, and you should be correcting for elevation as well. The tables only show 2-5* increments and~3-day intervals so interpolation is required. So, to be accurate, this is how you find whether it is "day" or "night". Thank goodness, common practice is to use the times based on take-off and landing because it should be apparent that as you climb, the times will all change - and you could, theoretically takeoff at night, climb back into day and then have night arrive again
Also, different jurisdictions have rules that vary in wording and complexity. For most, the (sometimes legal) rule of thumb was 30 min after sunset to 30 minutes before sunrise. That's a rough average but "close enough for government work". As far as I can fathom, that general rule is no longer part of the CFR so you might have to argue with a FAA inspector. Now to MSFS (or FS9/FSX for that matter) - all that is pretty convoluted and data-heavy. The sim does hold enough data to determine sunrise and sunset (but most accurate only at the moment the data is built in and 'slips' with each passing year.) MSFS may use more up-to-date data as part of the weather info downloaded with each use. However, I doubt the Logbook function would ever be robust enough to be anywhere near that accurate so they just grab something like sunrise/sunset, use the +/- 30 minute average, but I have doubts about how precise the Logbook would try to be for every user and location. Also, with all the variances of Standard vs Daylight Saving time, I'd bet they are only sorta close (and makes a good case for, like real-world aviation, using UTC). As for that, it's easy enough to set up a second clock in W10 to show UTC.
Bookmarks