nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Date Conversion Problems REST<->Silverlight

TitoMoreira

Hi all,

I've recently started using FeatureDataForm (ArcGIS Silverlight 2.0 API) and I'm getting problems with editing Date fields.

Everytime a user picks a Date, and Apply the edits the Date field is saved in the Database with one day difference (all the components are installed in the same machine).

This is most probably due to the difference between UTC time and New Zealand Time (UTC+12h).

I know that the REST API for editing features uses UTC date time values, and I have some tests which confirm that calling directly the REST UpdateFeatures operation works fine, therefore the problem must be in the Silverlight API. The Flex API also has the same problem, but we have found a way to solve it.

Does anyone know a workaround for this issue in ESRI Silverlight API 2.0 ?

Regards,
Tito Moreira
Eagle Tech Group, GIS Professional Services

Find more posts tagged with

Accepted answers

All comments

ChristopherHill

This problem also exist in the FeatureDataGrid. The problem in general is with the Microsoft datapicker creating DateTimeKind.Unspecified and the Database queries returning DateTimeKind.UTC which creates a bad user experience. We will be addressing this issue in FeatureDataGrid and FeatureDataForm.
http://forums.arcgis.com/threads/32404-DateTime-wrong-after-FeatureService-Editing

ArneDahlman

API 2.4
The problem is still there.
Any info when this can be fixed?

RobChouinard

Thank you for your post. We were able to reproduce the issue and have identified the cause. We will try to get the fix in for the future release.

How about an update on this ESRI? It's been over a year now.

Nevermind. The problem lies in the DateTime.Kind = "Unspecified" being mistaken for Local when doing a conversion to UTC when in fact the DateTime is already in UTC. The DatePicker changes the DateSelected.Kind to "Unspecified". My workaround was to put in a converter when binding to datepicker that converts the DateSelected to UTC with no time changing. Sad really.

ArneDahlman

Any news about this?
I Am also intrested to know when this issue can be fixed.

JeffRogholt

I installed the Silverlight 2.2 API but didn't notice this being corrected. Do you know when this bug will be fixed?

JenniferNery

Thank you for your post. We were able to reproduce the issue and have identified the cause. We will try to get the fix in for the future release.

TitoMoreira

Sure, no prob.

This is the updates parameter of the REST Request:
[{"attributes":{"OBJECTID":403,"CLAIM_ID":"CLM/2010/067368","INSPECT_DATE":1288522800000,"LOSS_ADJUSTER":8,"ESTIMATOR":7,"HAS_REPAIR_COMMENCED":1,"REPAIRER_NAME":null,"REPAIR_BEGIN_DATE":null,"REPAIR_END_DATE":null}}]

Just take a look at the INSPECT_DATE value. I chose 1 of November of 2010 in the DatePicker of the FeatureDataForm and the value stored in the database and sent in the request is 31/10/2010 (12 or 13 hours less).

I think the Silverlight API (ArcGISJsonWriter.GraphicsToFeatureServiceJson method) isn't converting the DateTime value correctly or MapService.Epoch doesn't have the correct 1970/1/1 DateTime value.

Cheers,
Tito Moreira

JenniferNery

Can you run Fiddler to see what date parameter it sends to the service? Kindly check post #14 on this thread http://forums.arcgis.com/threads/14730-Area-And-Perimeter. It should be similar approach in that when you run your SL app, grab the parameters from Fiddler. We will also check our end if we are doing something to the Date values.

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.