# NavList:

## A Community Devoted to the Preservation and Practice of Celestial Navigation and Other Methods of Traditional Wayfinding

**Sexagesimal conversion**

**From:**Paul Hirose

**Date:**2017 Jul 27, 21:03 -0700

In conversions from degrees or hours to sexagesimal, there are some fine points which are easy to overlook. For instance, convert 1.99992 to sexagesimal at 1 second precision. 1. Obviously, degrees = 1. 2. Minutes = .99992 * 60 = 59.9952 = 59 whole minutes. 3. Seconds = .9952 * 60 = 59.71. Rounded to the nearest integer, that's 60, so the angle will display as 1°59′60″. Oops. One solution is to convert the angle to the nearest multiple of the desired precision. In this case, precision is one second, so one "unit of precision" is 1°/3600 = .000277778°. When expressed in that unit, the angle is 1.99992 / .000277778 = 7199.71 units. Round to the nearest whole unit. (That can be accomplished by adding half a unit, then truncating the fractional part.) Thus the rounded angle is 7200 units. Convert back to degrees: 7200 * .000277778 = 2.00000°. When steps 1 through 3 above are applied to that value, the result is the correct 2°00′00″. Another issue is what happens when the angle rounds up to 360°. Do you prefer modulo 360 output? (I.e., zero instead of 360.) Also, bear in mind that the same routine may be useful to convert decimal hours to DMS, so perhaps the desired modulus can be be passed as a parameter to the routine. In that case, a modulus of 0 can be used to signal that no modulo adjustment is to be applied. Remember to adjust date if time rounds up to zero. For instance, the same instant of time may display as 23:59:59.9 or 00:00:00 on the next day, depending on the precision of the sexagesimal conversion. That behavior may be seen in my Lunar4 program. If you set the time a tenth second before the end of a year, and precision to .01′, the output shows the time you entered. But if you reduce precision to 1′, the time rounds up to Jan. 1 at 00:00:00. That happens because time is rounded to a precision comparable to the angular precision you request. (Actually, at .01′ precision the seconds display is 59.88, not 59.9, because the program automatically sets time precision 15 times greater than angle precision. Thus .01′ corresponds to .01 / 15 second, which is not a "nice" interval. Nevertheless, time is rounded to that increment for display. The roundoff *only* affects the display — for computations the program uses what you entered.) In some cases (altitude and declination, for example) you may have to deal with negative angles. The most foolproof method is to process the value as if it were positive, then restore the sign on output. Leap seconds are another thing to consider. If a minute ends in a leap second it's proper for seconds to equal or exceed 60. One solution is to pass the sexagesimal conversion routine a "step second" parameter. It's 1 if inside a leap second, 0 otherwise. In the former case, pass decimal hours minus one second to the sexagesimal conversion routine, which computes seconds in the normal way, then adds the "step second" parameter to the computed seconds. E.g., UTC time is 24.000028 hours (= 23:00:60.1). Subtract 1 second: 24.000028 - .000279 = 23.99975. Pass that last value to the sexagesimal conversion routine, and 1 as the step seconds parameter. 1. Hours = 23. 2. Minutes = 60 * .99975 = 59.985 = 59 whole minutes. 3. Seconds = 60 * .985 = 59.1. 4. Add the step seconds parameter to seconds: 59.1 + 1 = 60.1. All the operations I've described are implemented in my SofaJpl astronomy DLL for Windows. It also includes composite formatting for sexagesimal quantities, where a string controls the output format, as in the C language printf() function. This is a big convenience in applications like Lunar4, where a great quantity of sexagesimals must be formatted neatly, the flavor (D.d, DM.m, or DMS.s) and precision being unknown until runtime because they're under user control. http://home.earthlink.net/~s543t-24dst/SofaJpl_2_0/index.html