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