DateTime wrong after FeatureService Editing

[WilliamKimrey]

Hello all,

I have an application that edits using a FeatureService.  Whenever an edit is made, a Date Field is populated with "DateTime.Now"  When debugging, the time is correct at every step, but when I check the featureclass that was edited in the sde using ArcCatalog or ArcMap...the time portion of the DateTime is 5 hours ahead of the current time.

So, if I make an edit today at 3pm, the date being sent will be today at 3pm, but the date that ends up in the featureclass is today at 8pm.

I'm at a complete loss here as to why this is happening.  Does anybody have any ideas?  This is going to cause lots of problems if I can't get this fixed.

Thanks,
Will

[JenniferNery]

What are you using to edit the DateTime field? Could this be a related thread? http://forums.arcgis.com/threads/16644-Date-Conversion-Problems-REST-lt-gt-Silverlight What version of the API are you using.

If you are not using FeatureDataForm or FeatureDataGrid, try to specify DateTime.Kind when you set the DateTime attribute.

[WilliamKimrey]

I'm using v2.1 of the API and I'm editing the attribute using a FeatureDateForm (sort of).  The FeatureLayer Outfields don't include the Date field that I'm editing because we don't want the user to see that in the FeatureDataForm.  But, before we apply the changes in the form, I do the following:

            FeatureDataForm fdf = (FeatureDataForm)sender;

            fdf.GraphicSource.Attributes["EDITOR"] = username;
            fdf.GraphicSource.Attributes["EDITED_DATE"] = DateTime.Now;
            fdf.ApplyChanges();

Using Fiddler, I saw that this was sent in the updates for the EDITED_DATE field "1307997114182" and what was saved in the database was "6/13/3011 8:31:54 PM".  The time should be 3:51 PM.

I'm not really sure how that number breaks down into the date, but maybe you can tell me if the data being sent is correct or not and what to do if it isn't.

Thanks,
Will

[JenniferNery]

There was a bug fix in FeatureDataForm and FeatureDataGrid that dates back to 11/2010. I believe this was part of v2.1 release.

After you have selected a Date from the DatePicker in FeatureDataForm, can you verify that the Date value has DateTime.Kind of Utc? If this is still Unspecified, then this might be causing the issue.

The long number that you see is the equivalent long value for the DateTime. This should be correct as long as the DateTime have a specified kind.

[WilliamKimrey]

When populating the date with "DateTime.Now". the DateTime.Kind is "Local".  I switched over to using "DateTime.UtcNow" which does have a Kind of "Utc", but that resulted in the same issue.  In both cases, the time that my sde database shows in the featureclass is hours ahead of the current time.

[ChristopherHill]

FeatureDataForm fdf = (FeatureDataForm)sender;
fdf.GraphicSource.Attributes["EDITOR"] = username;
fdf.GraphicSource.Attributes["EDITED_DATE"] = DateTime.Now;
fdf.ApplyChanges();

Using Fiddler, I saw that this was sent in the updates for the EDITED_DATE field "1307997114182" and what was saved in the database was "6/13/3011 8:31:54 PM".  The time should be 3:51 PM.

1) Does your date actually say 2011 or 3011?
2) before you set "EDITED_DATE" does the attribute contain a DateTime mm/dd/yyyy or a Long(Ticks) 1307997114182
3) When you commit your save are you wired up to the Failed event handler.

[WilliamKimrey]

1) Yes, I did mean 2011.  Sorry about that.
2) Before setting the attribute with the new DateTime, it does have a DateTime (mm/dd/yyy tt:tt:tt AM) object.  This object includes the Day, Day of the Week, Kind, Hour, Ticks, etc.  There's a bunch of stuff in there.  The Date part of it is fine.  It's the TimeOfDay part that gets messed up.
3) Yes, the Save Failed event is wired up, but it's never triggered.

When I put a break point and debug at the point where the attribute is assigned, I can see that the "DateTime.Now" contains the correct information while the "DateTime.UtcNow" has the wrong information.  It seems that even though I"m assigning the first value, it's actually saving the last value.

[ChristopherHill]

This may be the problem the FeatureDataForm only edits the "Date" portion of DateTime. Currently the FeatureDataForm uses a DatePicker control for editing. the DatePicker control only changes the Date it will not update the time.

Example.

Original value : 1/1/2011 5:00:00 PM
DatePicker shows 1/1/2011
Modified value : 5/5/2011 12:00:00 PM
DatePicker shows 5/5/2011
ApplyChanges()

the date gets modified but the original value is not changed.
End Result : 5/5/2011 5:00:00 PM

Can you confirm that this is what is happening. Does the time protion ever change?

[WilliamKimrey]

That is not what is happening in this case.  The time portion is changing.  Also, this is not unique to the DatePicker .  I have instances where I'm changing the attribute in the code-behind by assigning "DateTime.Now" to it and bypassing the FeatureDataForm.

However, this problem occurs regardless of the method.  Here's the scenario.

1) Original Value (edited in ArcMap so it has correct time) => 6/16/2011 1:12:35 PM

2) Assign DateTime.Now to the feature's attribute (using silverlight app)
   2a) Before Saving, After ApplyChanges => 6/16/2011 1:15:40 PM
   2b) During FeatureLayer_EndSaveEdits => 6/16/2011 1:15:40 PM

3) Database now reads 6/16/2011 6:15:40 PM
   3a) When I edit the feature again, this is the value that I get.

Instances where I use the DatePicker don't need to have exact time because I really just need to know the day.  However, this field is what we use to track when edits are made to the data so in the event that something happens, we can tell the user things like "We have the data you entered before lunch, but everything after 1:00 PM will need to be re-entered".

[JoãoMendes]

I have the same problem. Any solution?