Saving updates to a survey XLSForm does not refresh Survey123 Connect Form Preview about solution.js

[MikeTschudi]

This error occurs because we replace the contents of the text files in the survey configuration zip file. While this is implemented in order to swizzle the contents, no modification of the contents is needed to replicate this bug: we simply read and replace text files. While the XLSX file is also read, it is not replaced back into the zip--it is left alone.

[chris-fox]

This is occurring because the date timestamps for the files are showing in the future for some files. See the screenshot below, I just took this picture and the timestamps for the Sign Request.xml file is showing as tomorrow. Survey123 Connect compares the timestamp of the xlsx file with this .xml file. If the xlsx file has a modification date newer than the xml file then it refreshes the xml file from the xlsx definition. Because the timestamp of the xml appears newer than the xlsx even after I save it doesn't refresh.

The update forces the xml to update and its timestamp is updated to now as a result. Is there anything we can do to control the timestamp of these files when we replace these files in the zip? Not sure if this is some UTC offset going on here.

[MikeTschudi]

Thank you, @chris-fox, for discovering this.

I'm marking every file with the same time.

• xlsx earlier than xml causes this issue as you discovered
• xlsx later than xml causes infinite loop asking if we want to update the survey
• xlsx with same date as xml works

S123 does something strange while unzipping, however: it adds the UTC offset to all files except the PNG and .itemInfo files. This puts the XLSX file hours into the future west of the prime meridian, thus breaking the update.

Merely correcting for UTC offset for all files leads to S123 to unzip all files to be approximately the same time, but all files except the PNG and .itemInfo files are one day in the future.

Merely subtracting one day for all files has the same effect as setting all files to deployment time.

Correcting for UTC offset and subtracting one day seems to be the solution.