Closed Parrazyte closed 5 months ago
This is a good suggestion, as I know that astropy highlights this as a warning. With the way that the current implementation of the survey data analysis is, this change is non-trivial.
In the future, when we improve the survey analysis capability we will be sure to do this so I will keep this open for now.
The fact that you tell me this is non-trivial makes me wonder if I haven't made a mistake.
In order to retrieve the Time of the observations, what I do is manually add a fixed MJDREF+MJDREFI according to the page I gave you, then "simply" add the Tstart in seconds.
Is this good enough ?
Of course, I'm missing the leapseconds, but for my purposes (daily integrations or at least hour to hour comparisons) few seconds don't change much.
Hi @Parrazyte,
Apologies for my confusion, I thought that this was a mosaic spectrum. The change is relatively straightforward to do and I think that you have already done it? Your value for DATE-OBS is different from what I have coded up in the bat_survey.py file. In any case, you can also get the real UTC date for a pointing observation from the BatSurvey object. There is some additional information here: https://github.com/parsotat/BatAnalysis/blob/main/notebooks/BatAnalysis_objects_intro.ipynb
The pha spectra obtained when running batspectrum_analysis (and probably the event files before) lack some temporal information:
-the file header only has a TSTART and a TSTOP
-the DATE-OBS is a constant set to '2022-01-26T12:16:00'
example:
The date-obs is signaled as fake, but it would be helpful to add MJDREF/MJDREFI keywords (from i.e. https://swift.gsfc.nasa.gov/analysis/suppl_uguide/time_guide.html) as well as leapseconds if they are necessary, and correct the DATE-OBS according to TSTART.