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?
Solved! Go to Solution.
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:
Any chance your time zone is set to the wronge location? Mine is set here
and I think mine was set automatically be the machine settings. Just a guess and something simple to check.
I haven't installed 10.3.1 yet, but just checked my test 10.3 and it still shows my timezone (and set the same as above). Maybe it's a change in 10.3.1??
I have 10.3 and was able to find the Time Zone setting. My time zone is set to Pacific when I need it to be Eastern. To change this do I just need to edit the REST?
Although you want to get it to the right zone, Pacific vs. Eastern shouldn't make a difference (unless you were working late/early hours....only 3 hours different). As mentioned, mine was set automatically when I installed, or at least I don't recall having to set it.
Have you check whether your machine is the correct data/time set?
If checking/changing the machine setting (and rebooting) doesn't correct it, I'm not sure the procedure for updating it in AGS. If that doesn't work, maybe someone else will be able to give some instructions (and I would be curious too).
It may be Jonathan has the correct info on why. But just to follow up on the INFO tab I pointed to, it does sound like it is read-only and reads the info from the server....so, that might not help any (assuming the server date/time is set correctly) but still good thing to know. (I found this in the AGS local help for the 10.3 install, fwiw.
It sounds like a difference between UTC and GMT. See this page for more information, excerpted below:
The date and time in a pop-up do not match the date and time in the underlying data.
Servers store dates in Coordinated Universal Time (UTC). Web browsers convert the date to local time. For example, if you look at a time field in a pop-up and you are located in California during standard daylight time, what you see is 8 hours earlier (UTC-8) than the time in the data. This offset might affect the date as well. If you look at a pop-up with data from 7/7/2011 12:00 a.m., you see 7/6/2011 5:00 p.m.
That definitely seems like it could be part of the issue. But we are collecting data throughout the day, and I would assume that some of it would still show up as the same day and so far I have not found this to be true. Also, it doesn't mention any type of solution on how to change the times. So am I to assume that it is just something that we have to live with?
Starting at 10.3.1, both map and feature service supports defining which timezone the date values are stored. This is per service level settings.
once you do that, map and feature service will use information to convert date-time values to UTC and you will get correct results in a query output.
for more information, please check the help on
"dateFieldsRespectsDaylightSavingsTime" in ArcGIS REST API .
only caveat for 10.3.1 is that you need to add them manually using Admin API/Site after the service is published... we are planning to improve that experience in future.
hope this helps.