Am I in error here or was there some fundamental change made in this area going from ags 9.3.1 to ags 10 or is it in the js api? If yes, then is there a list of all changes like this somewhere? It's very frustrating to have to find them like easter eggs.
The result set at 10 now also includes the data type of each return field in the alias collection that precedes the results. So now you cannot just ignore the data type and return it to the users eyes or else they will see that ugly date value. Now I'm wondering if there are other types that have been modified. Not pretty.
I'm also having issues now with inserting dates into features that I add to ags via my SOE. If i insert a new record and set the date field to 01/09/2011 and then i turn around and query that feature i get the epoch format back which i convert to .... 01/08/2011. Is there a time zone issue going on or something? Perhaps someone who was involved with the changes in the date handling could throw together some notes or, say, documentation about what was done and how to deal with the new way of doing things?
This info is from the rest doc: http://help.arcgis.com/en/arcgisserver/10.0/apis/rest/mapserver.html#response Support for time-aware map services was added at 10. If the map supports quering and exporting maps based on time, the response will include a timeInfo property which includes information such as the map's time extent and the map's native time reference. However, note that the REST API always encodes time in UTC (milliseconds from epoch).
Is this considered a new feature rather than a bug, then? There really should be some better documentation explaining why the REST date format has changed between 9.3.1 & 10... and how to handle it in the Web APIs...
Luckily the AMF format does not change the date values. Switching to using amf instead of json worked for me in my flex app. Not a solution for others using JS and Silverlight though.