These metadata dates are datetime values, incl… time and time zone. You may need to adapt the format (e.g. in Excel) or have a look with the modal view mode. You can also see the full content when you copy them into a string type variable or reference them in a note label.
Be aware that the start / end refers to the client device timezone, but the _submission_time to the server time zone. You can find some discussion around this issue with the search function of the forum, e.g. Multiple submissions randomly appeared all at once on server days to weeks after submitting - #2 by jnm.
For single modal edit, the end (datetime) values will be higher than the _submission_time (converted to the same time zone). But when using bulk edit, the end time is not changed!
Pre-condition is that both clocks/time zones are correctly configured.
Another workaround might be to save the first deviceid in a calculate form field (with a calculation once(${deviceid})) and check it against the (final) deviceid value, saved in another calculate field (here without once()). A check might even block saving the edit if there is a difference (e.g. using a required note with a relevant filter).
You might do something similar with a once() timestamp. (But this might block edit on client level too.) See also https://docs.getodk.org/form-logic/#lightweight-timestamping.
All these approaches will not track a deletion or a duplication of a submission!
In general, the most important might be to have the “right”, trustful administrator/owner of the project.
In future, when Enketo (Webform) will support dynamic read_only, another option could be to set a dynamic read_only for all questions at the end of the form, before submission (e.g. setting one variable which is referenced for the read_only). And only allow to reset this read_only on the same deviceid or with a special password. Dynamic read_only is already supported in Collect.
