Apps developed using Web AppBuilder are not showing our dates stored in ArcSDE (Oracle) correctly. For example, dates stored as midnight November 3 are displaying as November 2. I'm sure this is a GMT issue. Is there any way to fix this via an application configuration? Or does something need to be done at the web map or portal level?
Solved! Go to Solution.
At last! I found a simple, effective solution that works in Web AppBuilder! In env.js, I overrode the Date(milliseconds) constructor. See this thread for more info:
Popup behavior is defined at the web map level. Unfortunately, custom attribute display has no way of actually manipulating attribute values. Because ArcGIS Online/Portal interprets database dates as UTC and tries to adjust for local time, web map popups are barking useless for displaying the dates in our database. I suppose the next step would be to come up with a custom identify widget to plug into Web AppBuilder.
What a bleakered shock of crit! Because the ArcGIS REST API decided to return millisecond values for dates, this means that client apps based on different technologies are interpreting the same value differently. Client apps based on ArcObjects, ArcGIS Pro API, and various flavors of Runtime do not take that extra step to adjust for time zone.
I don't know what anyone else thinks, but to me this is a serious issue. As an experiment, I've created a server object interceptor (SOI) that takes query operations and converts date field type declarations and values to strings, so that all client apps will report the same value. But even this approach is potentially fraught with danger, as an app could still anticipate a millisecond value from a query, having examined the schema that the service publishes.
Why not have your SOI add change the time portion of the UTC date/time to be 6am instead of the default 12:am that way the localization of the date/time will not be an issue.
The fact that ArcGIS Server stores dates in UTC (millisecond format) is the proper way to handle a software product that is used around the globe. It is up to client app that uses this data to specify the format and how it will display the internationally accepted standard. The overall problem you are having is that the date field is really a date time field and if no time component is specified when the data is entered then midnight on the date entered will be used and stored, still no issue. The issue comes when the client app takes the UTC date and converts it to a Locale date time string. If the date time is 11/14/2015 12:00:00 and you are in US Eastern time zone then the UTC date will be adjusted for the UTC difference between UTC and EST which is 5 hours so midnight will now become 11/13/2015 19:00:00 (just FYI for anyone viewing this thread).
So my suggestion is edit your date data to contain times using ArcMap and a simple field calculation to take the current date in the field and set the time portion of the string to 06:00:00.
Or have the SOI do this by taking the UTC date and adding 6 hours (21600000 ms) to it.
Adjusting the data in the database (adding the time component) is the best approach as this will have the JS and the ArcOject solutions have the same date.
Unless there's a way to configure ArcGIS Desktop to work properly with UTC values, I have a problem with converting our database dates.
I think you are missing what I am saying and have been saying. ArcGIS Server returns dates in UTC. So if your data in your database has the time portion of the date then JS will likely have no issue with the UTC date returned by ArcGIS Server. By default esri stores dates in the date field using midnight unless a specific time is supplied (which does not using most date chooser components). If you would just try and add a time to your date that is NOT midnight and test you would see that what I am saying is true.