I know dates and times have been an issue in AGOL for quite a long time, so I'm hoping maybe someone has found a workaround that can help out.
We have data coming in from about 100 different stakeholders who are external to our agency. Most of them submit data via Survey123, but some of them bulk upload data from a CSV file using the Data Aggregation Widget in Web App Builder. (We know that's being deprecated, so that's a whole other issue.) For the bulk uploaded data, they do not have a time associated with them like the S123 records do, so they're automatically assigned a time of 12:00 AM. Because we're on Eastern time (UTC-5 or UTC-4 during daylight saving), the bulk uploaded data are always displayed in our various tools as 8:00 PM on the previous date. When data are exported from either the S123 website or Experience Builder, the export retains the correct date, but that's not helpful when they're trying to use either of those tools to review and verify data because everything online shows incorrect dates. Also, if they try to export data from the web app with the Data Aggregation widget, the export has the incorrect dates.
The folks who are bulk uploading their data are already doing a fair amount of work to get everything correctly formatted, so I'm hesitant to ask them to try some sort of additional calculation on their dates before submitting the data, especially because doing it incorrectly will really mess things up. I've tried setting the time zone of the web map to the data's time zone with no adjustments, but that doesn't carry over to any of the tools that use the map (it's also quite confusing for the records entered via S123 that do have a time associated with them). Does anyone have any suggestions for getting these bulk uploaded data to display the correct dates?
If you have access to the new "Timestamp Offset" field type give that a try, it should preserve some time zone info. If that doesn't work, see if you can set a more meaningful default time for the incoming dates, or add a field that checks what the data source is so you can compensate for the bad dates somehow (such as an Arcade expression that subs in a better time)
Hi @TonyaLong,
As mentioned above, the new Timestamp Offset field type could be an option. Another new field type that might be useful for you is the Date Only field type. This field stores values that don't contain an associated time value at all. This field type is not subject to change, the way that a Date field is. That means that when data editors enter a Date value in a Date Only field, the value is preserved even when viewed across different time zones.
This article introduces the new field types, and this article has more in depth tips and tricks for working with Date and Time data.
Hope that helps!