Date(milliseconds) constructor

MarkCederholm — Sat, 14 Nov 2015 15:54:22 GMT

After my previous flame, which I retracted, I'm going to try to make my case in a more civilized manner.

There is a serious problem with the REST API and the JavaScript API in the interpretation of database date values. If I write a client using ArcObjects, ArcGIS Pro, or a flavor of Runtime, I will not receive the same value for a geodatabase feature date field as I will via the JavaScript API.

I researched this issue, and discovered that this problem is due to the core JavaScript Date(milliseconds) constructor. OK, this is an ECMA standard, and I can deal with that. Nonetheless, I can't help but feel the frustration at writing different apps, using different technologies, that do not report the same value sent across a network the same way.

If there's one thing I really despise as a developer, it's having to create workarounds to what I consider to be fundamental failures. Yes, I can write a custom widget as an alternative to the web map popup, or I can write a Server Object Interceptor to deal with the REST response. I have successfully tested both approaches, but not to my complete satisfaction.

The fact is: I really, truly, don't feel that I should be doing that. Unless someone [hopefully] replies with a brilliant flash that makes me slap my forehead, I will be submitting an [or promoting an existing] idea.

Re: Date(milliseconds) constructor

MarkCederholm — Mon, 16 Nov 2015 19:13:34 GMT

I found a solution, which is to override the Date(milliseconds) constructor. It's not perfect (it won't work for people using the map viewer in Portal), but it works in a web app, anyway.

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

topic Date(milliseconds) constructor in ArcGIS JavaScript Maps SDK Questions

Date(milliseconds) constructor

Re: Date(milliseconds) constructor