Feature service date field is a day off

[ShawnHibbs]

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

[KristianFitzgerald]

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

[SubuSwaminathan1]

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

[RachelS]

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

[DonnyVelazquez]

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?

[DaleHoneycutt · Accepted solution]

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:

• If you need to enter your current date and time, use one of the time functions below, as these functions always return UTC time.
• If you are entering a date without a time component, add 12 hours to the date. For example, instead of entering '5/27/2014', enter '5/27/2014 12:00PM' or '5/27/2014 12:00'. The reason this offset is needed is that when a date is entered without a time component, it is entered as midnight on that date (5/27/2014 is converted to 5/27/2014 00:00:00), and when it is displayed in your local time zone, hours are added or subtracted. For example, if you are in PST and enter 5/27/2014, it will display as 5/26/2014 (seven hours subtracted from midnight on the 27th).
• If you are entering a date with a time component, apply your time zone offset to the time. For example, if you need to enter 5/27/2014 12PM PST, apply the seven-hour difference and enter  '5/27/2014 7:00PM'. To find your time zone offset, you can search the web using a search phrase such as UTC time difference calculator.
• To view the contents of your date field in UTC time, you can add a string field to your table and calculate it to be equal to your date field. The date will be converted to a string without the time zone offset. This string will also contain milliseconds.