RespectDaylightSavings Error after Portal 10.9.1 Upgrade

[AndrewKesterton]

Hi Survey123 community, 

Following an upgrade of our ArcGIS Enterprise to ArcGIS Portal/Server 10.9.1, hosted feature services that were created from Survey 123 Connect with a survey start and end time started returning an error on query; 

{"error":{"code":500,"message":"JSONObject[\"respectsDaylightSaving\"] not found.","details":[]}}

This error is only returned for queries with the the start and end times in the outputFields, if manually querying the feature service for different attributes then the data is returned OK. 

In the feature service definition, Survey123 Connect has created the feature service with a time zone defined, and the property: respectDaylightSaving (note the difference from the error, where it is looking for respectsDaylightSaving). 

The timeInfo section of the layer definition in the feature service looks like this;

 "timeInfo": {
  "startTimeField": "survey_start_dt",
  "trackIdField": null,
  "endTimeField": "survey_end_dt",
  "timeInterval": 0,
  "timeExtent": [],
  "timeReference": {
   "timeZone": "UTC",
   "respectDaylightSaving": false
  },
  "hasLiveData": false,
  "timeIntervalUnits": "esriTimeUnitsMilliseconds"

Using the Server Administration API I can change the time zone definition to instead have the property respectsDaylightSaving.  This corrects the error, and all queries return correctly.  The new timeInfo section of the service is below;

   "timeInfo": {
    "timeReference": {
     "timeZone": "UTC",
     "respectsDaylightSaving": false
    },
    "timeInterval": 0,
    "timeIntervalUnits": "esriTimeUnitsMilliseconds",
    "hasLiveData": false,
    "trackIdField": null,
    "startTimeField": "survey_start_dt",
    "endTimeField": "survey_end_dt",
    "timeExtent": []
   }

While that resolves the problem, it isn't ideal to manually edit all services created by Survey123.

Does anyone know which is the correct definition?  Is the bug with ArcGIS Server 10.9.1 in looking for respectsDaylightSaving, or is the bug in Survey123 connect for creating the service with the  respectDaylightSaving property on the time zone?

The only reference I can find is in this ESRI blog post from last year that indicates it should be respectsDaylightSaving.

Recreating the Error

 We are using Survey 123 Connect 3.13.246, and i can recreate the issue by publishing a new service using any template and adding the survey start and end times to the XLSForm;

type	name	label
start	survey_start_dt	Survey Start Time
end	survey_end_dt	Survey End Time

Once the survey is published, and the hosted feature service created by Survey123 connect,  if I then submit some records into the new hosted feature service it will start returning the respectdaylightsavings error above. 

Thanks for any help resolving this, I have also submitted a support case for the issue (#02958232).

Andrew

[JohnBickmore]

i have fixed the issue 

I went into the item details page for the form and saw that time settings were enabled

I changed the time settings Time Field used from the start date to a date and time within the survey

My dashboard is working again.

[JohnBickmore]

Now I have another issue with this Survey123 hosted service. I have a webmap with a table that allows export to csv. We now have records of 2100 pipes, however export is limited to 1000 records. When we try to update the json to increase this to 5000 we get this same error message again 

Error

  A JSONObject text must begin with '{' at character 1 of 50%)"
       },
       {
        "code": "Medium",
        "name": "Medium (25-50%)"
       },
       {
        "code": "Poor",
        "name": "Poor (

Code

  500

any advice appreciated 

[RyanUthoff]

Thank you so much for this post! We just upgraded to 10.9.1 and experienced this problem. Luckily I was able to see the error in the web traffic, searched the error message, and found this post. While I appreciate the attached notebook that includes a fix for this, I am disappointed that Esri didn't push out a patch for this issue (besides the S123 bug fix, which doesn't fix already published surveys). This is a software defect within Esri and a patch should have been rolled out to fix this (or at the bare minimum, have some sort of Esri documentation about it) instead of the "fix" being within some random geonet forum post.