How does DurationSinceLastTVQ resolve the 'last TVQ' in periodic/subscription Event jobs?

Is there any documentation that explains exactly how DurationSinceLastTVQ determines the `last TVQ` when used in periodic or subscription Calculation/Event jobs? I am trying to create a batch event that starts when a counter begins incrementing and ends after the counter has stopped changing for N number of seconds. The tag does not reset to 0 until the scale is tared, so I cannot use value = 0 as the event end condition. 

I would expect when using the DurationSinceLastTVQ function, it would return the elapsed millis since the last real stored value/quality change for the tag. 

I am seeing the function return results that appear inconsistent, and it seems like the function may be using an `Extended` good value at the calculation/evaluation rather than the actual last `Real` stored TVQ. 

When repeatedly clicking the Evaluate button, DurationSinceLastTVQ oscillates between ~10,000–~58,000ms, but occasionally returns what appears to be the correct value (57,948,295ms) before dropping back down. If the function were using the last `Real` stored TVQ, I would expect it to consistently return ~57948295ms counting up every time the Eval button is clicked.

I am using v26.2.0.26099

Questions for the group;

1. Does DurationSinceLastTVQ use extended/interpolated values when evaluating a tag at a periodic calculation timestamp?
2. If so, is there a way to force it to use only the last real stored TVQ?
3. Is there a recommended pattern for ending an event after N seconds of inactivity following the last real value change?
4. Is there a way to preserve the actual last real TVQ timestamp as the recorded event end time, rather than the evaluation timestamp?

The goal is for the event to end based on inactivity after the final real counter update, not when the tag eventually resets to 0 for the next batch.