Date(milliseconds) constructor

3058
1
11-14-2015 07:54 AM
MarkCederholm
Occasional Contributor III

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.

1 Reply
MarkCederholm
Occasional Contributor III

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