Re: JULDAY 5.4 not same as 5.3?

[Don Woodraska <don.woodraska(at)lasp.colorado.edu>]

I've pinpointed the problem.

SUMMARY:
***
The bug appears only with unsigned-long and unsigned-64-bit-long hour argument

to JULDAY.

The bug appears on lines 178-179 of JULDAY.PRO. Here it is:
 jul = TEMPORARY(JUL) + ( (TEMPORARY(d_Hour)-12)/24d + $
  TEMPORARY(d_Minute)/1440d + TEMPORARY(d_Second)/86400d + eps )

FIX:
***
Here's a fix:
 jul = TEMPORARY(JUL) + ( (TEMPORARY(double(d_Hour))-12)/24d + $
  TEMPORARY(d_Minute)/1440d + TEMPORARY(d_Second)/86400d + eps )


WHY IT WORKS:
***
When you take the difference of 2 different data types (dhour and long 12) the

result is automatically promoted to the data type with the most precision (at
least on our unix implementation).

Although an unsigned long has no more bits/higher precision than a long, it is

first in the expression evaluation. The result of 0ul-12l is an unsigned long
(4294967284 if you want to put a value to it). If you reverse the order like
this,
-12l+0ul, you get a long.

When a ulong64 is passed as the hour argument we get the expression
ulong64(0)-12l, which gives 18446744073709551604.

Cheers,
Don