Survey123 Date Only shows incorrectly on Report

RMill · ‎01-22-2025

Hello,

Recently I made a survey with survey123 connect. Within the survey is a date field that is set to default to today(). Originally when I published the survey I did not change any data types, however I noticed for post processing that the date field automatically tacked on the time, so default information was "%Y-%M-%D %I:%M:%S %p format. The time portion is unnecessary, so I changed the date field to esriFieldTypeDateOnly in the bind::esri:fieldType column. Since I have changed the data type, the date now shows up incorrectly when reports are generated using the Survey123 website, and by incorrect I mean they show up a day behind. The date is correct in the table, such as 1/22/2025, but then it will show up as 1/21/2025 on the report. I copied the survey and tried different data types, with the standard date data type and string working properly, just not the "date only" type.

I would like to try and not change the data type, but then it seems like the fix for that is on esri's end? Any information would be great, thanks!

RMill

The way I ended up fixing the report without republishing the survey was by adding a second date field in the survey that was the full date and time, no "date only" specifications, and hiding the date only field.

The reason for the move to DateOnly was to make scripting easier since I wouldn't have to worry about time formating. So I needed to keep the date only for the scripts that were already written, but needed a fix for the report. I also couldn't "hard code" time since the field techs are submitting surveys from multiple time zones. So now I just have the two date fields, the date only for scripting purposes, and the regular date field for report purposes. Since doing that, I haven't had any issues.

However, this only works for those for when the operator/field tech is submitting the survey on the day of the needed date since the hidden field is autopopulated.

For the record I did bring this up at the last Esri conference I wasn't given much of an answer... I hope this helps.

View solution in original post

SarahSinghNZ · ‎01-22-2025

Hello,

Is it possible that the discrepancy you are seeing is the difference between your timezone and UTC? Basically, the date/time data is stored at the database level in UTC but served up to the client in your local timezone which is set by the ArcGIS Online organisation.

Dates are converted to UTC when they're stored because the physical location of the server hosting the data and the people viewing the maps that contain the data can be anywhere in the world. Storing the time in UTC allows ArcGIS Online to transform the data to the correct local time zone regardless of the location of the server or the viewer of the application.

Source: https://doc.arcgis.com/en/arcgis-online/manage-data/work-with-date-fields.htm

RMill · ‎01-22-2025

I don't think thats it. I'm testing in CST while the previous sureys were submitted in MST. I'm testing with surveys submitted in the morning while the other surveys were submitted anywhere from 3pm to 10pm, which would put it in the same day as UTC - 0 zone. Currently, with the data type set to date-only, the time is either not collected or is removed, so the only data that gets to table in survey123 online is the date, there is not time to use to "correct" the date.
Now there is the "Edit" date/time stamp, but that is field cannot be used in the reports, so it shouldn't affect anything

DougBrowning · ‎01-22-2025

The problem is that the service backend always has time. They just released a date only last year but its not fully rolled out yet I think. This means it is probably defaulting to midnight UTC and then you can go a day back easy. How old is your 123? A few years ago they changed date only to noon to get around this. I wonder if setting the esri type is getting you. You can instead use date as the field type in column 1 in 123 and see if that is better.

For us in the end we just always have time. Its good info anyway and it reduces all these issues.

RMill · ‎01-22-2025

I'm using version 3.21.62 of S123 Connect. I have column 1 set to date, then also specified in the bind::esri:fieldType column so that I wouldn't have the time for easier processing later. Now I would have to republish the survey and lose data in order to change the data type back, which I would rather not do. Although its looking like I might not have another option.

DougBrowning · ‎01-22-2025

What is the data type in the service? It may be regular date then you can change the form fine. If not set the current field to hidden then add a second date/time field to your form. Calc over the old dates to the new dates and then you should be good to go. No need to start over.

Again this was defaulting to noon. Is it not now?

RMill · ‎01-22-2025

The data type is date, then I specified "DateOnly" in the esri field column. This actually functions correctly, on the online data table it shows only the date. It also shows correctly when I export the data to csv or excel.

My issue is when a report is made. For some reason in the report it goes back a day.

Report Template:

What's on the report (used the record highlighted above):

This only happens with the date only data type in the bind::esri:fieldType column.

DougBrowning · ‎01-22-2025

Check the actual data type in the AGOL service though. I would also add time to the report just to see what time it has. Probably midnight. I do not do much reports so not sure.

I do remember that starting a field name with a _ is an issue. Esp layer in queries. I do not think that is this issue though.

RMill · ‎01-22-2025

So went to AGOL, this is from the details page of that field from the "results" feature service (since its shared). Still shows as a date only type.

DougBrowning · ‎01-22-2025

Mmm maybe 123 has support but not the reporting. @ZacharySutherby ?