Response to JIRA GRINF-38
https://jira.slac.stanford.edu/browse/GRINF-38 (by Denis D, Lucas G, David S)
The fundamental issue is: providing information on the quality of the event-by-event absolute time stamps to the users of the FT1, FT2, and/or Merit files, primarily for pulsar phase analyses.
The definition of "adequate quality" depends on the analysis in progress. Loose timing precision is perfectly acceptable for a slow pulsar with low photon statistics (the bins of the phase histogram will be wide).
Furthermore, absolute time drift is not a simple function of time since GPS lock-loss. Eric Siskind provided a way to estimate the typical drift. Actual drift could be a bit better or a bit worse.
We therefore believe that to handle data samples with GPS-lock loss users should simply be warned about lock loss, and methods to evaluate the timing quality should be recommended by the Pulsar group. Suggestions below.
In light of this, it seems less important that a cumulated time-since-lock-loss variable be included in the end-user data files, especially if it is technically challenging to implement.
EXECUTIVE SUMMARY:
1) Having 'sourceGPS()' in the FT1 and Merit is essential (see https://jira.slac.stanford.edu/browse/GRINF-44) ;
2) gtpphase and/or gtbary should emit warnings, such as "events without GPS lock in this data sample", possibly listing fraction of events, duration, start and stop time, etc. A separate warning could be issued if the data set or data run had no GPS lock at the first event.
3) Users may elect to remove some time intervals from the analysis. gtselect and gtexpcube already handle selection on time intervals.
4) If the cumulated time since GPS lock was lost can be included in FT1 and/or Merit and/or FT2 and/or the metadata information then that is good and useful but not essential.
SUGGESTIONS TO EVALUATE TIMING QUALITY
1) The user can calculate elapsed time since GPS lock-loss within their own data sample, and use E. Siskinds' typical or maximum drift rates to estimate the deviation from true absolute time. [anders] How can the user do this if they only have individual, non-successive events from multiple runs and the only information per event is 'sourceGps()? <span style="color: #cc3333"><strong><em>(See Dave S reply #1 towards bottom of page.)</em></strong></span>
2) "Vela pulsar peak position versus elapsed time", as in Marianne's IRF monitoring tasks , will, in many cases, provide a limit on the deviation from true absolute time.
[]https://confluence.slac.stanford.edu/display/DC2/2008/03/05/Absolute+timing+using+the+Vela+pulsar
COMMENTS ON THE JIRA COMMENTS
A) The choice of the technical discussions mentioned by Anders & Jim are beyond us. Andrea Tramacere's slides for the FT2 review (link here) suggest that he knows quite well how to accumulate information across run and file boundaries [anders] No. FT2 is made on a per run basis. . So... if the digi L1Proc can generate a cumulated value to be stored with the metadata, then great! do it! And if a cumulated quantity can be stored in the FT2 (and the user then imposes some condition for it to then affect the GTI !?!?) then also good. [anders] We'll try 
B) Nota bene that Masa & James were thinking in December and January about how to add "ephemerides quality" messages to gtephem (link to his note, here). Perhaps if we start
adding "quality control quantities" to the files, we should do it consistently across ephemerides to timestamp space. In that case, space craft position precision might be thought about at the same time (although we expect it to always be right). See HERE for the "Five Easy Pieces of Good Phase Calculations".
C) Siskind reminds us in his comment that there is a 1 or 2 second lag in reporting GPS lock loss, and as much as a 20 second latency before reporting that GPS lock has returned. For most analyses, this is unnoticeable (see "slow, faint pulsars", above). For precision studies (high statistics on a millisecond pulsar?) the analyst will need to demonstrate adequate timing quality. (EJS: Actually, I remind you that even after the spacecraft reports that it has regained GPS lock, it may be up to 20 seconds until this is truly the case as far as the LAT is concerned. There is NO indication given when the PPS signal furnished to the LAT is locked to the PPS signal from the GPS receiver - only when the GPS receiver is locked to the GPS satellites.)
Dave S reply #1 It's post-processing by the User!
Say you have a few months of data in some few degree ROI near the galactic plane. 3 degree radius is 9*pi ~ 30 sq. degrees.
Is the all sky raw gamma rate about 20 Hz? So 10 Hz after "transient" or "source" cuts? Dominated by the Milky Way diffuse? The whole sky is 40 k square degrees. Milky Way maybe 5k square degrees?
So a W.A.G. for the gamma rate in the ROI is 10Hz*30/5k = 0.06 Hz, that is, 3 or 4 photons per minute. For the larger ROI's needed for gtlike, the rate is higher.
So now the analyst checks the time sequence of events without GPS lock in his data sample. He finds sequences of a few events here and there, and either says "times are probably fine for my slow, faint pulsar, I'll keep all the data" or he says "I'm a paranoid perfectionist working on a high precision analysis, I'll throw them away" and either way it doesn't amount to much.
-OR- the analyst find a sequence of hundreds of photons without GPS time lock, and he starts to calculate maximum drift. Or he checks the Vela peak position using Marianne's IRFmon tools. Or he just throws them away.
Anything wrong with my reasoning? David.