For tracking time, take a look at lightweight timestamping and (although it may be a little more challenging to parse) you can also enable a detailed audit log.
Thanks for the response! I will definitely check what you say out.
As for the number of times a repeat group has been executed, I am aware of count(). This is the same as CTO which I have been using for years. What I was hoping for was something where counting the repeat group could be done at a point in the survey so that people couldn't go back and add more.
This is similar to another use case for calculate_here which is that if you want to hand a tablet to a respondent and have them fill confidential things, you can then block backing up and seeing that after they hand it to the FO in CTO. But, without calculate_here, I am unclear if this is possible in ODK.
I realize that you are all answering as volunteers and I I really appreciate you. I myself used to program in Java like more than 10 years ago but now I am just trying to keep my head above water on my current day job while also taking a challenging online course in Data Analytics and managing my two kids, one of whom is autistic. Otherwise, I wouldn't just ask for a feature but offer to help (beyond beta testing).
The fact that you guys respond to questions is amazing. Thank you!
Hopefully the ideas @danbjoseph has shared address the lightweight timestamping need! In general, using the trigger column lets you control when an expression is evaluated: it only evaluates if the question referenced in trigger changes. Otherwise we don't have a concept of "here" in ODK. Please keep in mind SCTO forked a while ago so their engine and the mental models they build on may be quite different at this point.
We may need more details on your scenario to guide you with the second item. Here are two potentially related tools:
Setting to block moving backwards (described in "Form Entry Settings" here): this prevents ANY backwards movement so may be more aggressive than what you would like.
Sorry for the late reply. I appreciate the documentation on trigger.
In my case, I actually didn't need to use trigger in the end I think because I realized that I could use the relevance field in my calculate variable combined with once(). Since all my questions are required, I can check whether the question before where the calculation needs to occur is not null (so the last question in each section that comes before the next section). As soon as the previous question is filled out, then the calculate variable will execute once and mark when they reach the next section for the first time. Reading the documentation, I think I would use trigger for cases where I want it updated the last time not the first time the user reaches a spot in the survey.
As for my second use case where I wanted to prevent people from adding another instance of a repeat group and having that increment the count of number of repeat group instances, I could use the same strategy in that once they get to a certain required question, I can get the count of the repeat group using that same calculate field with relevance set to be not null for the spot where I want it to execute once() and give me the count of the repeat group.
The only case where I would think calculate_here would be better than using calculate with a relevance field or this calculate and trigger feature is in cases where the question you want to trigger on is allowed to be null (so it won't necessarily trigger) but there are very few cases in my surveys where things are allowed to be not required so this isn't an issue for me now anyhow.
So anyhow, thanks again for your answer. I'm glad to learn about trigger and lightweight timestamping. I appreciate the help!