Alas, I concede that it is “server” time because I made the regrettable mistake of using the duplicate (clone) submission feature in my attempts to try to debug this support case efficiently. I fear that describing <start> (or <end>) as “server” time really does nothing to help the original poster resolve his issue and will make for confusing reference material when encountered by future viewers. I must reiterate that these times always come from the client making the submission, even in the odd case (cloning) where the client is the server itself 
If you have further questions about this, please be so kind as to open a separate topic.
Yes. Maybe I’m wrong, though. I haven’t tested all scenarios (drafts, etc.) in all clients.
No, there is nothing internal or hidden. In most cases, this is what <end> contains. Just from testing for this discussion, I know that:
- For a simple submission, done in one sitting without saving or loading any drafts,
<end>reflects the time I click “Submit”. - For an edit, as we’ve seen,
<start>remains unchanged, but<end>gets set to the time when I click “Submit” on the edit.
For other scenarios, though, as I wrote earlier:
Next question:
XLS exports do not convert timestamps to different time zones. They do cut off the time zone offsets, sadly, when “Store date and number responses as text” is not checked—for the reason you mentioned elsewhere: “a disadvantage [to including the offset] would be that Excel will not show it as date.” The “Store date and number responses as text” option is available to cope with this limitation: it brings back the offsets. I’ve included an example below that illustrates how +00:00 and -04:00 offsets are truncated but not converted:
I could see it being helpful that the submission modal, being a detail view, shows the verbatim response including the time zone offset, while the table view—meant for viewing many records simultaneously—standardizes them to a single time zone (local time). I agree with you that it’d be better if the table view and XLS exports showed the same thing, but I’m not sure which approach is the best. I’d be tempted to convert everything to UTC, and then possibly provide options for viewing and exporting in local time. I’ve opened a new issue: How should time zones be handled? · Issue #3943 · kobotoolbox/kpi · GitHub.
I noticed that as well and made an issue for it before my last post: Reduce discrepancies between table view and single submission modal · Issue #3942 · kobotoolbox/kpi · GitHub.
