Hello,
I just noticed an issue with my feature services that I published from ArcServer. Every date field is a day off from what it should be (i.e. the date is 8/3/2015 in the enterprise geodatabase itself, but is showing up as 8/2/2015 in the feature service). If I convert the field to a string it comes in fine. Does anybody know what might be causing this?
Thanks
Solved! Go to Solution.
I'm currently investigating a related issue that arose with our SOAP based data access starting at 10.3.1. The problem does not exist in 10.2.2 or 10.3. The problem only seems to occur when the feature service has Date fields included in the underlying map document. All edits to these records through the feature service fail immediately with "incorrect parameter" errors in the ArcGIS Server logs from the time the edit failed.
My investigation led me here since I figured the new Timezone functionality at 10.3.1 could be related.
I've tried setting the dateFieldsTimezoneID that Tanu mentioned above by modifying through the admin/services webpage, but even though I enter the value directly after maxRecordCount property in the JSON (as is instructed here: ArcGIS REST API), it ends up moving to a different location after I click Save. After I save the property is listed after "isCached" instead of after maxRecordCount.
I'm currently not able to determine whether this setting is being ignored or honored since the problem (edits fail for all records) still exists.
I will be continuing to investigate, but wanted to post here to see if anyone could shed light on what's happening.
Thanks,
K
Kristian,
The timezone related field do move about on save and I am using them successfully on a map service. Have not tested in a feature service though.
If you do have problems with edits failing on a feature service, try to get contact folks in the esri Feature services team through tech support maybe. They are the ones who created this functionality.
Subu
Kristian,
Did you ever get this resolved?
I'm in the same position I've set the datefieldtimezone and daylight savings as per Tanu's message above, saved it and it's moved in the properties but is there.
However, it hasn't made a difference to when I edit a date field. It's still in UTC rather than local time.
Rachel
How do I get the value of dateFieldsTimezoneID without logging into rest admin? If someone changes this from the default then I can't just convert the UTC value to local on the frontend, correct? I would need to know what the dateFieldsTimezoneID value is right?
This is from http://doc.arcgis.com/en/arcgis-online/use-maps/work-with-fields.htm
The bold text is mine. It might be the issue you're seeing(?)
"Date fields in tables are assumed to contain UTC date and time. UTC stands for Universal Time Coordinated, and it is nearly equivalent to the current time at Earth's prime meridian (zero degrees longitude) located near Greenwich, England. UTC is a more precise version of GMT (Greenwich Mean Time). Dates are assumed to be UTC because the physical location of the server hosting your data can be anywhere in the world. The alternative of storing date and time in a local time zone leads to all sorts of problems, especially if you, or the server hosting your data, move to another time zone.
Whenever a date field is displayed, the date is converted from UTC time into your local time. This is done by querying your computer and asking it for its time zone setting. For example, suppose your computer is set to Pacific Standard Time (PST). PST is seven hours behind UTC—when UTC time is 9:00AM, it is 2:00AM PST (or 1:00AM depending on whether daylight savings time is in effect).
Any date you enter in an expression is assumed to be UTC time, not the time in your current time zone. This assumption can lead to confusion. For example, if you enter '05/27/2014 05:00:00PM' using a computer set to PST, it will display as 5/27/2014 10:00AM due to the time conversion described above.
To account for the UTC-to-local-time-zone conversion, here are a few tips: