Switch to using UCTS timestamp?

[maxnoe]

From a discussion with @FrancaCassol, since UCTS is in principle the more precise timestamp and by design the component meant to provide the timestamps, we should probably switch to just using the UCTS provided timestamp instead of the dragon counter based timestamp, at least for data after the TIB firmware upgrade that fixed most of the issues related to unreliable UCTS info in the files.

Opinions, @moralejo, @rlopezcoto?

[rlopezcoto]

Sounds good, but if we have to reprocess some old data, it would be great to get a check that selects the dragon counter based timestamp for data before TIB firmware upgrade

[moralejo]

Ok with me too. Would a runnumber-based default behaviour be fine?
I understand we will still calculate the dragon timestamp, and keep checking for possible jumps in the ucts info, correct?.

[maxnoe]

I understand we will still calculate the dragon timestamp, and keep checking for possible jumps in the ucts info, correct?.

For now, yes. The question is what to fill into the ctapipe event.trigger.time field after that has happened

[maxnoe]

Would a runnumber-based default behaviour be fine?

Yes, or date. For the use_flatfield_heuristic, which has the same underlying cause I think (the TIB firmware upgrade) we check if the run was after 2022-01-01.

Let's do the same here?

[moralejo]

We also have recent data in which the UCTS info was not available, but ok, we will just have to override the default in those cases.