Date Display

[MarkCederholm]

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?

[MarkCederholm]

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.

[MarkCederholm]

I have decided that the "correct answer" is that there is no correct answer to this dilemma.  I researched this issue, and came to the conclusion that it's JavaScript's fault.  With their grit-eating shins, ECMA decided that the JavaScript Date(milliseconds) constructor would not only create a date value, but would also, oh-so-cleverly, convert it from UTC to the local time zone as reported by the browser.

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.

I'll continue testing this approach against various client technologies, but because this seems to be exclusively a JavaScript issue, it probably makes more sense in the end to deal with it on the client side.

[RobertScheitlin__GISP]

Mark,

   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.

[MarkCederholm]

Sorry, correct me if I'm wrong.  The REST API returns a date value as a JSON integer which represents milliseconds, which JavaScript takes on its merry way.  After review, I don't see how I can adopt your suggestion.  In any case, my core disgruntlement issue is still that the milliseconds value returned by the REST API is not truly dealt with in a unified way by the "ArcGIS Platform".  Were I to convert all my database times to UTC, that still wouldn't solve the issue.  In fact, in the context of ArcGIS Desktop and ArcFM, that may well make the situation far worse.

[RobertScheitlin__GISP]

Mark,

   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.

[MarkCederholm]

I thought you meant there was some way I could include timezone awareness in the response.  The problem with adjusting the time value itself is that, while it will now appear correct for JavaScript clients, it will no longer appear correct for clients based on ArcObjects, ArcGIS Pro, and Runtime, whereas a formatted string will appear the same for all clients. And if I edit the data itself to represent UTC in the database, I'm not sure of the ramifications in ArcMap/ArcFM and our existing non-JavaScipt apps.  I'm still trying to sort out all these possibilities, and potential consequences, in order to decide which is the best approach.

[RobertScheitlin__GISP]

Mark,

   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.

[MarkCederholm]

That is absolutely untrue!  I realize I may be beating a dead horse, but I just can't seem to get the point across.  I already have some feature classes that store dates in UTC, and have published them to a feature service.  If I use ArcMap or ArcGIS Pro to identify a feature, whether through the DB connection or the web service, the date displays as the literal UTC value stored in the database, not local time.  If I edit the feature and supply a date via the calendar widget, that local time is literally what's stored in Oracle.  If I query the web service in Runtime, the feature object returned has the date as it's stored in the database, not local time.  Only the JavaScript API returns the date differently.

Unless there's a way to configure ArcGIS Desktop to work properly with UTC values, I have a problem with converting our database dates.

[RobertScheitlin__GISP]

Mark,

   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.