Understanding FITS Time Record

Sequence Generator
1

Greetings!

I’d like to better understand the times recorded in the FITS header of acquired frames.

Here’s an example from one of my recent images:

DATE-LOC 2023-05-24T23:45:26.0000000 Local observation time
DATE-OBS 2023-05-25T06:45:26.0000000 UTC observation time

The exposure time was 300s (5min). Does this time represent:

  1. when the file was written (which would be several seconds after the end of the exposure)?
  2. the actual end of the exposure?
  3. the beginning of the exposure?
  4. or something else like the mid-point of the exposure?

I’d like to get the mid-time of the exposure from this FITS value, but to do that I need to know what specific time is being recorded.

Thank you very much for your attention to this question!

Best Regards,
Ben

2

Hi Ben,

DATE-OBS is a nonstandard FITS keyword. It was introduced by SBIG (bought out by Diffraction Ltd.). FITS File Header Definitions says:

DATE-OBS – date of observation in the ISO standard 8601 format (Y2K compliant FITS): CCYY-MM-DDThh:mm:ss.sss. The Universal time at the start of the exposure is used. Note: the alternate format using DATE-OBS and TIME-OBS is not written, but MaxIm DL will correctly interpret it when read. The time is written to 10 ms resolution. The default behavior is to report the start of observation time, but individual camera drivers can change this. As of Version 6.24 the DL Imaging driver sets the time to exposure midpoint.

So there is NO standardized point in time specified for DATE-OBS.

The corresponding standard FITS keywords with specified point in time are listed in https://fits.gsfc.nasa.gov/standard40/fits_standard40aa-le.pdf :

DATE-BEG (start date/time of observation),
DATE-AVG (average date/time of observation) and
DATE-END (end date/time of observation).

Bernd

3

Thanks, Bernd!

I appreciate the link.

My camera is a QHY model. Do I understand correctly then that the QHY camera driver writes DATE-OBS to the header, or does SGP do that itself? If the former, I’ll need to check with them on what time this represents.

However, if it’s the latter, does SGP document this somewhere, or could somebody from SGP please verify? Thanks!

Ben

4

I was having a related issue just the other day and Ken (SGP founder) says that they write the start time provided by the camera or “guess” at the time if no time is provided. Note that the time is only to the nearest second in spite of the precision of the format. I don’t know what “guess” means as Ken has not gotten back to me with an explanation. I have the QHY 268M.

Kent

5

To be fair, you never asked that question of me? I seem to be the last reply on your thread here…

That said, it’s no problem explaining… The notion of a guess here means that SGPro can only know the time it requested your camera start integrating and not the exact time that camera actually started integrating. SGPro cannot know the actual time the camera began its integrarion, but this guess will be sufficient for most. This is why we always favor the camera’s onboard time (when it provides it) as opposed to the integration request time. It is supposed to be more precise, but in the issue you describe it is not. This can be fixed within the QHY ASCOM driver… seems like there is some rounding going on there somewhere…

6

Hi Ken,

I was wondering why you hadn’t responded as you are always very prompt. I figured you might be busy but I must have forgotten to hit reply when I replied to the thread asking for an explanation. Sorry! Thanks for the explanation. Using system time for the “guess” then. Good enough!

Fixing the driver sounds like the way to go.

Thanks,
Kent

1 Like