| Bug in IDL's TIMEGEN function [message #55585] |
Fri, 24 August 2007 13:11 |
Dave Wuertz
Messages: 6
Registered: August 2007
|
Junior Member |
|
|
Folks,
I found a bug in IDL's TIMEGEN function. It really nailed me good, as I
was using the (erroneous) results from TIMEGEN to compute direct-access
locations within database files.
First off, I'm running IDL v6.4 on a 32-bit Linux-Intel box.
TIMEGEN returns an incorrect sequence of julian dates when STEP_SIZE=-1,
and UNITS="Months" when crossing year boundaries as demonstrated in
the simple example below. Note the results *should* be monotonically
decreasing.
IDL> MyTimes = TIMEGEN( units="Months", step_size=-1,
start=julday(1,15,2007), final=julday(10,15,2006))
IDL> print, MyTimes - MyTimes(0)
0.0000000 -396.00000 -61.000000 -92.000000
This way gives the same erroneous result:
MyTimes = TIMEGEN(4, units="Months", step_size=-1, start=julday(1,15,2007))
However, if you go forward in time (i.e., with a positive step_size),
the function crosses the year boundary correctly:
IDL> MyTimes = TIMEGEN(units="Months", step_size=1,
final=julday(1,15,2007), start=julday(10,15,2006))
IDL> print, MyTimes - MyTimes(0)
0.0000000 31.000000 61.000000 92.000000
In the last example I swapped the dates for "start" and "final" and made
the step_size positive.
The dangerous thing is that the function returns a valid date, usually
withing a year or two of the correct date, so some programs (like mine)
can hum along just fine all the while subtly screwing things up!
I have filled out an "Incident" report at ittvis.com, but have not
gotten a response yet.
-Dave Wuertz
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
