comp.lang.idl-pvwave archive - RDF feed
type: channel
description: Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado
items: Problems with JULDAY and CALDAT
items: Re: Problems with JULDAY and CALDAT

Problems with JULDAY and CALDAT
type: item
description: I've been developing a set of time conversion functions (primarily using Modified Julian Date) and I have discovered some problems with the IDL-provided routines CALDAT and JULDAY. 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. 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. (It also mishandles preceding leap years, but those are before the the Gregorian calendar took effect in 1582 and it becomes increasingly difficult to make sense of those dates anyway.) Instead of Feb 29, (Year), it returns Feb 31, (Year+1). The problems are easy enough to work around, if you know what the problems are. I have attached a small sample procedure to demonstrate what I've found. Does anyone know of other problems, or a better pair of routines, or a plan to update these two? John Boia PRO TIMETEST FORWARD_FUNCTION JULDAY B = julday( 1,1,1970,0,0,0 ) - 0.5D PRINT, B, FORMAT="(' Jan 1 1970 0h UT --> JD ',F15.3//)" FOR I = 2299160L, 2307639L DO BEGIN CALDAT, I, MON, DAY, YR JD = JULDAY( MON, DAY, YR ) IF I NE JD THEN BEGIN FOR J = I-2, I+2 DO BEGIN CALDAT, J, MON, DAY, YR PRINT, J, MON, DAY, YR, FORMAT="(' JD =',I8,6x,'Cal:',3I5)" ENDFOR PRINT ENDIF ENDFOR END -- John J. Boia | Email: jboia@iasdev1.gsfc.nasa.gov Programmer/Analyst | Web: http://iasdev1.gsfc.nasa.gov/~jboia/ Computer Sciences Corp. | Phone: 301.794.2357
creator: John J. Boia
date: 1999-04-07T07:00:00-00:00

Re: Problems with JULDAY and CALDAT
type: item
description: John, The off-by-a-half day problem was fixed in version 5.1 of IDL. Cheers, Scott Lett John J. Boia <jboia@iasdev1.gsfc.nasa.gov> wrote in message news:370BC459.167E@iasdev1.gsfc.nasa.gov... > Wayne, thanks for the references. Will have a look. > > I checked JULDAY just like your example and got different results > from what you got! > > IDL> print,julday(4,7,1999,0) > % Compiled module: JULDAY. > 2451276.0 > IDL> print,julday(4,7,1999,12) > 2451276.5 > IDL> print, !version > { mipseb IRIX unix 5.0.2 Aug 19 1997} >
creator: Dr. G. Scott Lett
date: 1999-04-07T07:00:00-00:00

Re: Problems with JULDAY and CALDAT
type: item
description: landsman@stars.gsfc.nasa.gov (Wayne Landsman) writes: > 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/ Wayne, thanks for the plug, although I never expected to see that software used for dates as long ago as 1582. Since the main thrust is to handle leap seconds for conversion between TAI and UTC, it really isn't valid (at the one-second level) for dates earlier than 1972. There is one important distinction between JULDAY/CALDAT and our respective software packages. It appears that the routines JULDAY and CALDAT try to handle the conversion between Julian dates and Gregorian dates. Dates starting with 15 Oct 1582 and onward are assumed to be in the Gregorian Calendar, while earlier dates are assumed to be in the Julian Calendar. CALDAT applies the reverse of this process, converting Julian day numbers greater than or equal to 2299170 into the Gregorian Calendar, and smaller numbers into the Julian Calendar. Thus, there's a jump from 4 Oct to 15 Oct 1582. This isn't explained in the documentation for either routine. On the other hand, both DAYCNV and my own software work exclusively in the Gregori…
creator: thompson
date: 1999-04-08T07:00:00-00:00

Re: Problems with JULDAY and CALDAT
type: item
description: William Thompson, thompson@orpheus.nascom.nasa.gov writes: > But then, we didn't have a whole lot of satellites > up prior to 1583 (that I know about). ;^) You probably know this, but in case anyone is tempted to relate, say, Kepler's planetary observations to more modern ones it is necessary to bear in mind that: a) Not all European countries changed calanders in the same year. b) At that time, the 'year' did not necessarily change on the night of Dec31/Jan1 - and the change day could also be different for different countries. Within one country this can vary with the type of record - rather as if modern fiscal years were recorded using only the start year so that Feb '99 becomes Feb '98. There are books with tables that will let you calculate the 'date' for any given day in any given country, but with published records you need to do a bit of archival digging to find out if the published date uses the calander of the author, his sponsor or the publisher - all three could in theory be different - and with private letters all bets are off. Struan
creator: Struan Gray
date: 1999-04-09T07:00:00-00:00