Re: Problems with JULDAY and CALDAT

[landsman(at)stars.gsfc.nasa.gov (Wayne Landsman)]

In article <370B879B.41C6@iasdev1.gsfc.nasa.gov>, "John J. Boia" <jboia@iasdev1.gsfc.nasa.gov> writes...

>CALDAT does not correctly return the month/day/year
>values for Julian day numbers that correspond to leap days
>(Feb 29) in the leap years 1584 through 1604.

John,

    As a replacement for CALDAT, you might look at DAYCNV.PRO available at 
http://idlastro.gsfc.nasa.gov/ftp/pro/astro/daycnv.pro. It passes your time
test for all years except for the peculiar year 1582 itself.

    (I don't know what the algorithm error in CALDAT is, since it uses a
different algorithm from DAYCNV.PRO.   But CALDAT does have a most un-IDL like
programming style, with a special subroutine that only does scalar calculations
that is called in a loop.  Ugly.)

Although not directly to your question, you might also look the time utilities
in IDL written by Bill Thompson at 
http://sohowww.nascom.nasa.gov/solarsoft/gen/idl/time/

>JULDAY seems to return Julian date values with an offset
>of 0.5 from the accepted definition, when hours, minutes,
>and seconds are passed in as arguments  Integer julian
>day numbers correspond to 12:00 noon UT.

I'm not sure what you are referring to here -- I don't see any problems with
JULDAY.   JULDAY should return an integer value when the hour is 12:00 noon --
which it does.

IDL> print,julday(4,7,1999,0)
       2451275.5
IDL> print,julday(4,7,1999,12)
       2451276.0

--Wayne Landsman                              landsman@mpb.gsfc.nasa.gov