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.
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