Issue with date/time fields not displaying with the correct timezone.

[NathanKoski]

We recently deployed an ArcGIS Online app made in web appbuilder for our customers to help communicate electric power outages. The map is viewable to the public.

(see link: https://allete.maps.arcgis.com/apps/webappviewer/index.html?id=cdbd5b27e6e94d8b81091b1fe04bc67b)

We have received feedback from a few customers that the ETR (Est. Time to Restore) and Date Off Fields are showing incorrect times which are several hours in the future. When I investigated I realized that they were seeing the times displaying using the UTC timezone, and not the Central US Timezone timezone that all our data is published in, and so all the timestamps are appearing to them as +5 hours. The feature service was configured when it was created to be in the Central Timezone. During testing, we noticed during testing that the time fields will display in whatever timezone the viewing device is using, so we have hypothesized that the customers reporting this error must have something interfering with the map's ability to detect their timezone, and so the map is defaulting to UTC. Getting more detail on the devices from the customer is a challenge, and not likely to happen.

Is there a way to change the app, map, or feature service so that all times will always display in the Central Timezone? We do not have any customers outside of Central Time, and so having the timestamps altered automatically like this simply generates more confusion.

Thanks!

[Michael_Knapp]

There is another thread from 2016 with similar issues.  

Hi - I'd like to add information as well.  This is a broader issue than just hosted data in ArcGIS online.  At this point the forced UTC time is causing huge issues for us across the ESRI platform.  We use ArcGIS online for public use and mobile editing but store our data in our own sql databases in local time and publish the service in local time.  We also use ArcGIS Enterprise portal for editing.   The user experience because of the development around the date/time (there appears to be disconnects between the app and the geodatabase and services development) is that they select a date in the ArcGIS enterprise editing against our editing service for the date of burial.  The date actually is CHANGED by the application and it stores a different date than the user has selected in the database. 

For example, we use this for our cemetery and it has resulted in a different date of death than the user entered..  So for example in the portal web editing, the user sees 9/20/1962 for date of death, but the database stores 9/21/1962 in the date of death field.

We have followed all the information and recommendations for publishing out in the local time zone and it has worked in previous versions.  No it is not a reasonable solution to just "switch" the date/time of the database server to UTC time - that is a large change with lots of impacts and as a local government organization.  It is also not a reasonable recommendation to ask that each date field have two fields - one with local and one with UTC and we are supposed to script that translation - that is a huge overhead.

For our organization, this erodes trust in the ESRI platform - we absolutely do not want the platform changing the authoritative entry that is happening.  It is a very serious issue to have an application actually change the information that is being entered.

From a quality and protection of data in an asset this needs to be addressed by ESRI.  The solution of asking clients to just use UTC time is unreasonable.  The solution of the application actually changing the data that is entered is downright scary from a protection of data perspective.  At this point the date fields are not usable for us and we are looking at other (all bad) options.