Issue with Dates and FeatureLayer.applyEdits

[RobertScheitlin__GISP]

I am having an issue with storing a FULL datetime back to SDE when using FeatureLayer.applyEdits.

The scenario is the user has a dialog where they choose a date from a mx DateField and also has a yahoo TimeStepper where they choose the time. A new date is created in ActionScript using this line:

vvar bDate:Date = new Date(DTPicker1.selectedDate.fullYear,DTPicker1.selectedDate.month,DTPicker1.selectedDate.date,DTPicker3.value.hours,DTPicker3.value.minutes,0,0);

Which when debuging shows the date as:

bDate = <Sun Nov 6 19:00:00 GMT-0600 2011> (@d3150c1)

This is accurate as the date entered in the Dialog was 11-6-2011 7:00 PM Central Standard Time. What is entered in SDE though is 11/7/2011 1:00:00 AM (not talking about what is returned by Flex).

I'm not sure what do do here.

[Anonymous User]

Robert,  Feature objects returned by ArcGIS Server represent the number of milliseconds since epoch (January 1, 1970) in UTC. This would explain why you see 11/7/2011 1:00:00 AM.  When you display dates in Flex you can use Flex's getTimezoneOffset() to convert dates from one time zone to another.

Feature Object Dates
http://help.arcgis.com/en/arcgisserver/10.0/apis/rest/feature.html

Flex stuff
http://livedocs.adobe.com/flex/3/html/help.html?content=08_Dates_and_times_3.html

Hope this helps. 

Doug Carroll, ESRI Support Services SDK Team
http://support.esri.com/

[RobertScheitlin__GISP]

Doug,

  I would understand that if the value when opening the MXD that the Feature service is coming from did not have the value of "11/7/2011 1:00:00 AM" actually written in the date field.

[IvanBespalov]

Some time ago we had the same problem.

Sample.

[RobertScheitlin__GISP]

Ivan,

   have you verified what is actually being written to the date field in your GeoDatabase?

[RobertScheitlin__GISP]

This is the code I ended up having to use to get the correct dates entered in my SDE (SQL Server 2005)

                                var bDate:Date = new Date(DTPicker1.selectedDate.getFullYear(),DTPicker1.selectedDate.getMonth(),DTPicker1.selectedDate.getDate(),DTPicker3.value.getHours(),DTPicker3.value.getMinutes(),0,0);
                                offsetMilliseconds = bDate.getTimezoneOffset() * 60 * 1000;
                                bDate.setTime(bDate.getTime() - offsetMilliseconds);
                                attribs.Begin_Date_Occ = bDate.getTime();

[Anonymous User]

Hi Robert,

I did not have the exact documentation you were looking for this morning but found the documentation this afternoon.  This discussion can get complicated fast, but the long and short is that ArcGIS Server stores dates in UTC.  This server feature is to help keep track of editing given that people can edit the same data source (feature service) in different timezones.

This topic was covered in our troubleshooting section in the help. 

http://help.arcgis.com/en/arcgisonline/help/index.html#//010q00000007000000

Certainly there may be better ways for handling dates, so if you have ideas please post them to the ideas site.
http://ideas.arcgis.com/

Regards,
Doug Carroll, ESRI Support Services SDK Team
http://support.esri.com/

[RobertScheitlin__GISP]

Doug,

   Thanks for the info. It would be nice if the APIs would make this very clear, or handle the conversion automatically, or only accept UTC dates.

[JohnGravois]

A documentation enhancement was logged recently to provide additional clarification to developers regarding this issue.  Please don't hesitate to contact Esri technical support to add your name to the list of customers requesting that the issue be resolved.

[NIM077729 Enhancement: Include information in the documentation to notify developers that it is expected behavior that local time will be converted to UTC when editing, but that they must add their own logic to convert back to local time when retrieving features.]

[PhilipThompson]

John, I think this is a really bad solution. Ultimately this isn't what ArcMap does. ArcMap stores the local date and time.

I can enter a date via the Flex API and it ends up in the database at -1 hour. Using ArcMap editing the same field it goes in correctly. I can even use ArcMap to edit the data via the Feature Service and it goes in correctly. This obviously isn't using the REST API but that should make no difference.

The vast vast majority of users don't share data across time zones. It is a use case to suit a tiny minority which will inconvenience the vast majority. At the very least there should be an override within the API which allows you to choose whether your date will be local or not.

Thanks Rob for posting your solution. It confirms the approach that I'm going to take but which I assumed just couldn't be correct.