Survey123 Date Only shows incorrectly on Report

[RMill]

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]

I was reading back over the information in the link that SarahSinghNZ attached. It says that unlike the other date types, with date only "the field is stored as a string field in the ArcGIS Online feature data store". I'm not fully sure if it would apply in this case... but could this be it?

[LMedeirosUI]

I think this particular bit of information refers specifically to how you add the field to your feature layer. And should be reflected in the data type when looking at the field's information.

If you happen to know why my field is exporting to excel with a leading backtick (aka the grave accent), I would appreciate knowing. Doesn't matter if it's a timestampOffset or DateOnly bind::esri:fieldType - still get the leading backtick when exporting to Excel. No backtick when exporting to CSV format. Going crazy.

[danbecker]

Same experience here with dateOnly field. It shows 10/21/2025 in the feature service (Survey123 website data tab), but when printed to a feature report ${monitoring_date | format:"MM/DD/YYYY"} it will be 10/20/2025. 

default calculation is today() in Survey123 connect. I recently changed that to now(), maybe that will make a difference?

Did you ever get this solved?

[RMill · Accepted solution]

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.

[DougBrowning]

You could have the hidden field use the value of the not hidden field instead.

[danbecker]

ESRI: 

Please weigh-in here... why does Date Only display correctly on the S123 website, but incorrectly on the feature report? 

S123 Connect 3.24.30 XLS Form

Feature service (Enterprise 11.5)

Feat. service attribute table in Pro 3.5.3

Sample individual report template (Generated by S123 website)

Resulting feature report PDF shows 10/22/2025 and NOT 10/23/2025 like it should. 

The fix! Just add utcOffset to the feature report, like so:

The resulting PDF now prints 10/23/2025 like it should. 

This is throwing a major wrench in the engine.