Y2k bug in astcalc()
jstottsj wrote on Apr 05, 2010
I stumbled across this while trying to add ST and AIRMASS headers to some old data. astcalc() seems to be mis-handling two-digit years.
Suppose I have a command file for astcalc() like this:
Since the only difference is the formatting of the date string, nothing should change.
When I feed it into astutil, what I actually see is
-JS
Suppose I have a command file for astcalc() like this:
# Only difference is the date string passed to mst(), so they should be the same
printf("%10s %s\n", $GMD, mst($GMD, "20:00:00", 110.000))
printf("%10s %s\n", $D, mst($D, "20:00:00", 110.000))
# Supply my own strings, year is pre-2000 as a check
GMD = "1995-04-05"
D = "05/04/95"
printf("%10s %s\n", GMD, mst(GMD, "20:00:00", 110.000))
printf("%10s %s\n", D, mst(D, "20:00:00", 110.000))
Since the only difference is the formatting of the date string, nothing should change.
When I feed it into astutil, what I actually see is
astutil> astcalc commands=astcalcBug.txt
mst() using current date settings
2010-04-05 1:36:02.36
05/04/10 1:32:57.62
mst() using pre-2000 date settings
1995-04-05 1:34:35.50
05/04/95 1:34:35.50
-JS
Mike Fitzpatrick wrote on Apr 05, 2010
Thanks for the report. The task is working as described, although perhaps not as expected. Whether this is a 'bug' is a question for philosophers and poets.
What's described is that the '$D' builtin variable returns the date DD/MM/YY format, what you might not expect is that the FITS time standard says this format is meant to be interpreted as a pre-Y2K date and so the task is technically doing the right thing by treating this as a 1910 date.
Since I couldn't think of a good (or bad) reason why anyone would want today's date 100 years ago, I've modified the task for the next release so the $D returns the date string as the post-Y2K YYYY-MM-DD format. Using your earlier test shows the results are now the same. If you tell me what platform you're on and need the fix quickly I can give you a new binary, otherwise this is fixed in the next release.
Cheers,
-Mike
What's described is that the '$D' builtin variable returns the date DD/MM/YY format, what you might not expect is that the FITS time standard says this format is meant to be interpreted as a pre-Y2K date and so the task is technically doing the right thing by treating this as a 1910 date.
Since I couldn't think of a good (or bad) reason why anyone would want today's date 100 years ago, I've modified the task for the next release so the $D returns the date string as the post-Y2K YYYY-MM-DD format. Using your earlier test shows the results are now the same. If you tell me what platform you're on and need the fix quickly I can give you a new binary, otherwise this is fixed in the next release.
Cheers,
-Mike
jstottsj wrote on Apr 05, 2010
fitz
If you tell me what platform you're on and need the fix quickly I can give you a new binary, otherwise this is fixed in the next release.
Now that I know the problem exists, I can just convert my date strings into four-digit years, so there's no rush to get a fix. I just wanted to save some time for the next guy.
-JS
Last post on Apr 05, 2010