Not really a question, but wanted to share this workflow. It might help someone who's tackling a similar challenge.
We’re piloting a new way to mobilise Oil Spill Response Ltd. (OSRL) via a Survey123 online form. But introducing this digital option surfaced a subtle technical challenge: how Survey123 handles timezones. This post shares how we tackled it.
Even when users manually choose a time zone from a defined list, there's a hidden gotcha: Survey123 saves times in UTC, based on the device’s local clock.
So if someone in Singapore reports an incident that happened off India’s coast but enters the time in India Standard Time without adjusting for their own device’s timezone, the result is an incorrect UTC conversion on the backend. That mismatch leads to incorrect entries in the feature service and a lot of head scratching later.
To store the right UTC time, you have to convert any time entered into the survey into the device’s timezone first before it’s submitted. That had my head scratching for hours.
Here’s where we landed.
The form now presents three key time references back to the user:
This isn’t just for show. Presenting the relevant different time zones can help users spot obvious errors like entering a future time by mistake or selecting the wrong timezone. It’s a subtle but powerful form of validation, helping avoid confusion later without slowing things down.
I'm sharing this in case others are tackling similar timezone complexity with Survey123 and I’d welcome any feedback or improvements you’ve think would make this better. Also if I've made a mistake, letting me know would be useful too.
Many thanks to @IsmaelChivite for his excellent article Dates and Time in Survey123.