From a logbook perspective, you really only care about whether you are legal to fly at night and how much "night flying" you can log. There are a few other informational things you might care to log, but these are the most important.
Being current per FAA 61.57(b) to fly at night requires that you have done 3 takeoffs and landings (to a full stop) within the prior 90 days, between one hour after sunset to one hour before sunrise.
It's a surprisingly simple statement, but in a quick read one might miss that there's 2 distinct concepts of night there: "night", and the restricted period between sunrise and sunset. They're not the same.
You'd think that the definition of night is simply the time between sunset and sunrise, right? Uh, no, that would be too simple. Rather, the FAA defines night as "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". Which simply begs the question of what the heck "civil twilight" is. The simple definition of "civil twilight" is when the sun is below the horizon, but by less than 6°. Simple, right? So to determine the start/end of civil twilight, you just get out your sextant and look for the sun while it's still below the horizon to measure it's angle and, oh, umm, never mind.
It's not actually that complicated. Sunrise/sunset are easy to find; pretty much any aviation app (including MyFlightbook) can tell you sunrise/sunset at a given location. Take that time span and restrict it by an hour at both ends and that tells you when you can do your takeoffs/landings to satisfy your 61.57(b) recent flight experience.
"Night" is, of course, trickier, since civil twilight isn't reported in many places and you can't see it. It's generally fine to guesstimate it and use 20-30 minutes after sunset/before sunrise as the cutoff points.
You can also use a tool on MyFlightbook that I've developed. It's a bit rough because it's meant as a debugging tool rather than as a full product feature, but you can click anyplace on earth and specify a date and you can get the times for sunrise/sunset at that location on that day, as well as a map of 24 hours showing the sun's angle against the horizon (in 5-minute increments), enabling you to see when civil twilight begins/ends, and when the 1-hour window begins/ends.
But there's a simpler way on both: if you use the MyFlightbook app on iOS or Android, and have it autodetect takeoffs/landings, it will figure out all of this for you and fill it all in on your behalf, both landings and night time. Or, if you use the web site and have a time-stamped GPS track of your flight (such as GPX/KML or a variety of other formats), you can press "Autofill" and the system will figure this all out for you. This will use the correct measurements of night for you.
So now you've logged your night flying. How do you log your day flying? You may have noticed that MyFlightbook generally doesn't have the notion of logging "day" times. This is deliberate: you have three variables (day, night, and total), two of which are fully specified (night/total); mathematically, the third variable (day) has a unique value that can be computed from the other two. Giving you the opportunity to enter it explicitly wastes your time if you do it correctly, and introduces errors if you don't. If you want to know your day-X time, just subtract the night-X time from the total-X time. (See my separate post about combination properties for more information about this).
There are a few bits of interesting technical trivia/arcana here:
- The apps will detect night-takeoffs in addition to full-stop landings. But your currency may show that you are current even if you do not log the night-takeoffs. They are absolutely required! But so many people are lax about recording them that I just give a warning when I find the required landings but do not find the required takeoffs.
- Logging night time is surprisingly tricky. Specifically, there is no way to take a starting and ending point and time and determine how much of the flight was "night", because the specific path can affect that. E.g., a flight from San Francisco to London might go north or south of a great-circle route for winds, and thus affect how much of the flight is conducted with the sun more than 6° below the horizon. MyFlightbook solves this by looking at successive GPS samples (latitude, longitude, and time) and accumulating the elapsed time between them if both samples are "night." Gap in the samples can lead to errors. For example, if a sample comes in at 8:00pm and that is not night, night begins at 8:02pm, and the next sample comes in at 8:05pm, then 3 minutes of night will be lost. As a practical matter, iOS and Android devices report GPS samples multiple times a second, so gaps like this are rare unless the device can't get a good view of the sky. If presented with simply a starting and ending point and time, the website will construct a synthetic path between those points, assuming a perfect great circle path and a perfectly constant speed, and compute the total night based on that. This is obviously an imperfect approximation, but it should be reasonably good, especially for shorter/slower flights.
- Many ratings require some amount of night flying, often as PIC or solo or cross-country. Per my post about combination properties, just log these attributes independently; the system will determine the appropriate amount of combination to credit towards your rating.
- If you fly turbine aircraft, you may find that MyFlightbook isn't reporting the usual 90-days of currency. This is because MyFlightbook also implements 61.57(e)(4), which provides an alternative mechanism for currency. Your night currency will be the later of either 61.57(b) or (e)(4)
- If you use the AutoFill feature on the website and don't provide a telemetry file (GPX, KML, etc.) but do provide a route consisting of a starting and ending point (no intermediate points), and start/end times in UTC, then MyFlightbook will estimate the amount of night flight by creating a pseudo flight path which assumes (a) a perfect great circle route and (b) a perfectly constant speed equal to the great-circle distance between the start and end divided by the elapsed time.