NavList:

   

Reply

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

   

Reply