nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Find more posts tagged with

Accepted answers

DaleHoneycutt

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.

All comments

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?

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

DaleHoneycutt

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

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.

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

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,

ahoque

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.

ShawnHibbs

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

RebeccaStrauch__GISP

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

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.

RebeccaStrauch__GISP

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

ShawnHibbs

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

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

SubuSwaminathan1

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

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.

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.