Identify Task : Date Fields

[__Rich_]

More date-related questions 🙂

I can't seem to use the built-in value formatters (inside a popup etc.) for dates returned from an identify task.

I don't know if this is a red herring but the query task and identify task for the same service and same layer return different representations of date fields i.e. fields with a data type of esriFieldTypeDate:

• Query = 1344270936000


• Identify = 06/08/2012 16:25:45

Does anyone know why it's done this way?

Is this the reason why the built-in formatters within PopupTemplate etc. don't seem to have any effect on the latter?

This should 'just work' shouldn't it?

[__Rich_]

OK, I now know why it's not being formatted client-side, it's because esri.substitute does recognise it as something that might be parsed as a number and since the date-formatting code is within the 'number' branch it never makes it to the DateFormat nor DateString formatters 😞

I think that could be rectified client-side i.e. a better attempt to be made to determine whether the value might be a date or not...perhaps I'm missing the point but the field type being esriFieldTypeDate does provide a bit of a hint, does it not?!

Why the two server-side methods return different formats for the same field remains a mystery, perhaps someone from ESRI could explain as this seems to be the crux of the problem?

[__Rich_]

Anyone know why Identify returns the date/time as a string and not an integer like Query does?

Or better still, does anyone know if you can force AGS to return as an integer...or even better can you force AGS to return it as an ISO-8601 formatted string?

TIA

[KellyHutchins]

The differences between Query and Identify is the expected behavior. The Identify (and Find) operations always return results as formatted text - even numeric values are returned as strings.

You can workaround this by creating a new date based on the date string then format that value. For example,

feature.attributes.created_date = new Date(result.feature.attributes.created_date);
var template = new esri.InfoTemplate("Attributes", "${created_date:DateFormat(datePattern:'MMMM d, yyyy.',selector:'date')}");

[__Rich_]

The differences between Query and Identify is the expected behavior. The Identify (and Find) operations always return results as formatted text - even numeric values are returned as strings.

You can workaround this by creating a new date based on the date string then format that value. For example,

feature.attributes.created_date = new Date(result.feature.attributes.created_date);
var template = new esri.InfoTemplate("Attributes", "${created_date:DateFormat(datePattern:'MMMM d, yyyy.',selector:'date')}");

Thanks for the response, Kelly.

But this needs to be done inside a template definition, not hard-coded in an external custom function, I'm trying to use out-of-the-box stuff where I can.  What you're telling me is that all numbers, dates etc. returned from Identify cannot be formatted inside a template without custom pre-parsing, surely showing Identify results in a popup has got to be the #1 use case so that's very disappointing.

Also, this doesn't solve the time-zone problem.  If you create a date from a string in JavaScript where the string does not have time-zone information then JavaScript (in compliance with the spec.) sets the time-zone to the user's local time.  This means, for example, that the date as returned from AGS will have a different time on the client-side for someone in the UK to someone in the US.

For example, try the following:

var dt = new Date("06/08/2012 16:25:45");
alert(dt.toUTCString());

For me, in the UK, I see "Fri, 8 Jun 2012 15:25:45 UTC", you will see a different value, one relative to your time-zone.

One more thing, the ambiguous format returned form AGS also doesn't make it clear to any parser whether the month or the day is first, this is also illustrated by the above example.  (the data were from the 6th August, not the 8th of June)

I know how I can workaround some of this stuff, I ask the questions, because, IMHO, I shouldn't have to, especially considering the cost of commercial (ASP) AGS licenses, this is basic and should have been more carefully considered.

Whenever you send date and time strings over the wire, use ISO-8601, the decision to use the format that's currently employed by Identify (and Find!) is, IMO, a poor one, I hope it gets addressed very soon.

Sorry to sound so negative, but I've now got so many 'workarounds' in place to cover things like this that I'm getting pretty fed up.

But I do appreciate you taking the time to respond 🙂

[__Rich_]

Since there's been a few threads where the format differences of return values between tasks have caused issues for people, I thought it might be worth posting this here, following a support call, I got this logged:

The ArcGIS Server Identify task returns a date field as text string instead of the epoch time that i...

[SteveCole]

Awesome news, thanks! Now if it actually gets fixed.....

[SusanaMirón_Lucio]

Any news about this?

We have the same issue, but we edit the feature class with Date attribute from ArcGIS Collector for Android and try execute Identify Task from web Viewer

Thank you in advance