nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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?

Najděte více příspěvků označených jako

Accepted answers

MarkCederholm

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:

http://stackoverflow.com/questions/13839318/javascript-override-date-prototype-constructor

All comments

MarkCederholm

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:

http://stackoverflow.com/questions/13839318/javascript-override-date-prototype-constructor

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,

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

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.

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.

Připojte se k diskusi

Přihlášení členové mohou přispívat, sledovat aktualizace a další. Jste tu noví? Zaregistrujte si bezplatný účet.

Rychlé odkazy

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.