Hi -
I am posting this here because I'd submitted a ticket to Esri Technical Support and they did not get around to testing my case until after Daylight Savings Time. This issue self resolved once DST was passed, however I strongly feel as if this is a bug and wanted to bring it to the community/Survey123 team's attention. Please see below for details - these details were relevant before 3/10/24 when scheduling an appointment for a date after DST. I am happy to provide more details if anyone is interested.
I have a Survey123 form which has been in use for about 5 years now. We use a series of calculations with date and time to schedule appointments. We are having issues with the Survey123 field app, version 3.19.120, installed on Windows desktops where any appointment made AFTER Daylight Savings Time results in an incorrect appointment end time. I have attached a copy of the XLSForm here and a Word document with some screen captures showing this example (please note this XLSForm contains a series of pulldata calculations which reference a protected hosted feature layer, so these will not work, however this will not impact testing the issue below).
Steps to reproduce this issue:
Each appointment was exactly 1 hour off (too long) in the end time.
Could you please upload your XLSX?
I did a quick test, and was getting the expected outcomes.
My set-up:
My tests:
As I clearly mentioned in the post, this issue self resolved once we got past DST on 3/10. This post was made to hopefully, make the Survey123 team aware of a potential bug since Esri technical support did not test my case until after 3/10 when the issue had already self resolved. This was not an issue in a web form or on iOS - only the Windows field app.
Example of issue from 3/8/24 with appointment date/time before DST - it worked fine:
Example of issue from 3/8/24 with appointment date/time after DST - notice additional hour in Appointment End:
The XLSForm syntax for the Appointment End calculation has been unchanged in my form for about 5 years, and has always worked as expected/reliably. In addition, we have always started taking appointments before DST for dates after DST without issue.
date-time(decimal-date-time(${Decon_Appt_Start}) + 0.013888889)
You can manually adjust for DST on PC though, which I did:
There may be something else at play. I am not aware of any strange interaction between DST and apps beyond this one system clock setting, but that doesn't mean that there aren't any.