Feature service date field is a day off

ShawnHibbs · ‎08-03-2015

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

DaleHoneycutt · ‎10-01-2015

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.

View solution in original post

RebeccaStrauch__GISP · ‎08-03-2015

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.

SubuSwaminathan1 · ‎08-03-2015

Rebecca,

Interesting that I do not even see Time Zone listed in ArcGIS Server 10.3.1. After version info, the next things is Supported Operations.

Thanks

Subu

RebeccaStrauch__GISP · ‎08-03-2015

Hi Subu,

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??

ShawnHibbs · ‎08-03-2015

Hi Rebecca,

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?

RebeccaStrauch__GISP · ‎08-03-2015

Shawn,

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).

RebeccaStrauch__GISP · ‎08-03-2015

Shawn,

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.

JonathanQuinn · ‎08-03-2015

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.

ShawnHibbs · ‎08-03-2015

Thanks Jonathan,

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?

Shawn

TanuHoque · ‎08-27-2015

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 "dateFieldsTimezoneID" and "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.