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; } } }

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

Finde mehr Beiträge mit dem Tag

Accepted answers

All comments

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.

previous_system.png

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?

WilliamKimrey

There really isn't a solution, just a workaround. I have to offset the date that I'm saving by the number of hours that get added.

So, in my case, since it's adding 5 hours to my time, I went from using "DateTime.Now;" to using "DateTime.Now.AddHours(-5.0);".

It was explained to me at the IUC that while the application will show the correct time and appear to send the correct time to the database, the base functionality of using REST will always use UTC time instead of local time.

MatthewDickinson

I came across this same problem. To take into consideration different local times and daylight savings, I used this to correct the times:

private DateTime CorrectDateTime(DateTime dateTime)
{
    return dateTime.Subtract(dateTime.ToUniversalTime().Subtract(dateTime));
}

arcgis rest services edit datetime universal

gisscconsulting

In javascript

new Date().getTime() - (3600000 * 5);

ChristopherHill

This issue has to do with DateTimeKind.Unspecified, DateTimeKind.Local, DateTimeKind.UTC

When you create a DateTime using DateTime.Now you get DateTimeKind.Unspecified which is represented in your local timezone, when you save this to the database it gets saved conveterd to UTC, then when you get it back you must convert it back to Unspecified or Local before you display it (if that is your desired format).

example:

client (create new date)                                database (UTC)
1/1/2011 12:00:00am local(PST -8 hrs) - >   1/1/2011 8am UTC
1/1/2011 8:00:00am UTC                     <-    1/1/2011 8am UTC

On the client side it is up to the user to either make sure that when they show the DateTime they are consistently showing the same DateTimeKind otherwise the user will get the impression that the date is wrong when its not, its just being shown in a different unit of measurement then they orignially started with.

think of it this way
example:
client            database
1 meter ->   3 feet
3 feet     <-   3 feet

the problem is the user only see the value and not the unit of measurement in which the value is being displayed, which makes it seem like the data has changed.

We are adding the ability for the user to control what DateTimeKind they want the client to see for example (FeatureDataGrid.DateTimeKind = DateTimeKind.Local)
we will assume that with this value the user wants all dates represented in local time and we will make sure all UTC dates are converter to Local before displaying inside FeatureDataGrid. If you however choose to diplay the date somewhere else or within your own control you will have to handle making sure that the DateTimeKind is consistent for what you would like the user to see. The conversions use DateTime.ToLocal() and DateTime.ToUniversal()

Nimm an der Diskussion teil

Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registriere ein kostenloses Konto.

Schnellzugriffe

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