New behavior in UTC offset in Date field in V3.5.177?

251
2
Jump to solution
09-11-2019 07:54 AM
WilmaRobertson
New Contributor III

We live in the Mountain Time Zone and have noticed that the UTC offset is included in our date fields when we export the survey results to a .csv file. Up until recently this has been 6:00 or 7:00 depending on whether we are submitting a survey while in summer or winter time, which makes sense to us.

When we upgraded our Survey123 app from V3.5.164 (which appears to process the UTC offset correctly) to V3.5.177 the UTC offset is now listed at 18:00 for any surveys submitted using the V3.5.177 version, which makes no sense to us – it appears to be 12 hours off.  There does also seem to be a different in the UTC behavior when the date field is set to a default of today() - which results in a rounded UTC that appears to be 12 hours different than what we expect, vs. a date field with no default where the UTC seems more random to me.

I have attached a word document that shows the questions as well as sample .csv downloads that illustrate the differences that we are seeing.

Having the correct offset is very important to us, because the data is fed into a custom script that uses this UTC offset to reconcile the time collected in another question in the survey with a time field in an different application where the script is feeding the data into.

 

Are we doing something wrong, or is this a bug? It appears that the behavior of the survey app changed when the new version was released. We tested it side by side yesterday: some folks here are still running V3.5.164 and their data seems to go in correctly and those that upgraded appear to have the UTC issue.   If it is a bug, is it fixable?  If not, what can we do to get it back to an offset of 6:00 or 7:00 (depending on summer/winter time).

 

Thank you and have a great day!

Wilma Robertson

0 Kudos
1 Solution

Accepted Solutions
Shwu-jingJeng
Esri Regular Contributor

Hi Wilma,

In 3.5 hotfix1(v.3.5.176), we made a change to store local noon time(UTC12:00PM) instead of previous midnight(UTC12:00AM) for today() and date question. That's the reason you are seeing 12 hours off with current build of field app. As the timestamp in date question is to capture the correct date, I would suggest you to use a datetime question to manage your data for further custom script purpose. 

View solution in original post

2 Replies
Shwu-jingJeng
Esri Regular Contributor

Hi Wilma,

In 3.5 hotfix1(v.3.5.176), we made a change to store local noon time(UTC12:00PM) instead of previous midnight(UTC12:00AM) for today() and date question. That's the reason you are seeing 12 hours off with current build of field app. As the timestamp in date question is to capture the correct date, I would suggest you to use a datetime question to manage your data for further custom script purpose. 

View solution in original post

WilmaRobertson
New Contributor III

Thank you for the information. Looks like we will have to make some tweaks on our end then.

0 Kudos