Hi David and All,
I just want to check what time system is used when TESS observations are imported using the Kepler/TESS FITS file v2.2 and QPL FITS file V0.2 plugins. I understand that BJD - 2457000 is recorded in the FITS files.
Does VStar just add the 2457000 before displaying a light curve in Barycentric Julian Date, or is the time converted to JD or HJD?
The difference is at most about 4 seconds, but it would be best to know which system is being used. Cheers,
It had been a long time since I looked at the Kepler plugin code I initially wrote with input from Doug Welch in 2010 and 2011.
So, I needed to go back and look at the code. :)
Here's what I wrote in the header comment of the first version of the code:
* A Kepler FITS file v2.0 observation source plug-in that uses the
* Topcat FITS library.
* See also:
* o http://archive.stsci.edu/mast_news.php?out=html&desc=t&id=392
* o http://archive.stsci.edu/kepler/manuals/ArchiveManualNewFormat.pdf
* o http://archive.stsci.edu/kepler/manuals/KDMC-10008-001_Archive_Manual.pdf
* In section 2.1.2 of the archive manual ("Kepler Time System"), we have:
*"Time is specified in the data files with an offset from BJD, either
* BJD-2400000.0 (light curve files) or BJD-2454833.0 (target pixel files)."
* This is at odds with the header comments in v2.0 light curve files. The
* correct time base for light curve data appears to be 2454833.0. Thanks to
* Doug Welch for helping me tracking this down who also suggests that the
* BJD-2400000.0 reference was probably intended to be MJD and 2400000.5.
In any case, as Kristen Nygaard (co-creator of the Simula language) said: programming is understanding.
Of a sort at least.
Here are the relevant code lines:
double timei = tableHDU.getHeader().getDoubleValue("BJDREFI");
double timef = tableHDU.getHeader().getDoubleValue("BJDREFF");
double barytime = ((double) tableHDU.getElement(row, 0));
double hjd = barytime + timei + timef;
Loading an example FITS file using the Kepler plugin and source and examining values in the running code yields these values:
timei: 2454833 (integer part; consistent with the comment above)
timef: 0 (fractional part)
The earlier comments make me wonder about the use of the variable name hjd here (obviously intended to denote HJD). I need to think about that. Not that it impacts the values computed, just the habitability of the code.
Max and Cliff have worked on the code for this and the QLP plugin more recently than I, and Brad Walter has had some input into the docs for the Kepler plugin. They may wish to comment further on what I have said.
I'm not sure if this helps or hinders your quest for understanding.
Happy to talk/think more about this.
What I recall from my work on the kepler plugin is there is no attempt in it to convert from BJD to HJD. The time is simply annotated as being BJD. As David notes above, the time base is changed with each mission and somewhere along the line we switched from using a program constant for the time base to using the FITS header value.
That being said, there is a bit of a larger issue which has been discussed, but which has not really been addressed well. This is the fact that when we say HJD we generally are implying the UTC time scale while when we say BJD we are generally meaning TDB time scale and often explicitly stating that. BJDTDB is what these missions use. While the light travel time difference between BJD and HJD is seconds, the time scale difference between UTC and TDB is an order of magnitude or more larger.
I do not believe VStar or any other AAVSO system deals with differences in time scale.
I know this is not particularly helpful, but it is something I have run into before.
Thanks Cliff and David,
so, if I understand correctly, TESS observations imported into VStar have had 2457000 added to the FITS header time and are BJD.
Perhaps this could be noted in the plugin documentation so people are aware and can make corrections to any measurements made from the data (e.g. Times of Minimum). Cheers,