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

[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()