This still seems to be a problem. Any updates on implementing a fix? Thanks
Keith Reed
While the hosted service stores dates in epoch time, UTC, date fields will always show in the local time in a web browser. That's because the web browser converts dates to local time.
Here's something that I thought of that may work for you. I added a new string field to my layer and used the field SQL (not Arcade) calculate option (On the data tab) to calculate the my stringDate field equal to the date field. The result was that the stringDate field contained the UTC date value as a string. I was then able to edit the string value of the date and then calculate the date field equal to my stringDate field. Since the calculation happens on the server. it's all in UTC time, as the server does no timezone conversion. The server seems to handle the data type conversion automatically (date to string and back). This approach will require you to periodically calculate the date field as edits are made to the stringDate field. Just an idea.
Mike
Hello,
I'm having a similar issue with the time settings.
I have a hosted feature service that is shared with members of my professional community all around the globe.
When analysts are putting the data into the layer, they are referencing information reports that give the time of the event in UTC+0, or what we call "Zulu" time. We do this because the community has agreed to use a standard time zone for all reporting to avoid confusion. No matter what time zone you are in locally, the event will be reported uniformly as "0700Z(ulu)."
When the analysts copies the time from the report, he unwittingly is putting the wrong time, as the system is assuming he means local time.
My need is two fold:
A) I need to be able to run the layer on a uniform time zone of UTC+0
B I need the time to display for all analysts around the world in UTC+0 and not in their respective local time zones.
Hey Trip,
You can do this by including a the following publishing parameters in the publish call in the REST API or ArcGIS API for Python.
Include the time zone in which your data is using.
"dateFieldsTimeReference": { "timeZone": "Pacific Standard Time (Mexico)" }
-Kelly
Thanks. We are adding the csv through a python script since it's being consumed from machine controls and not using the add item or drag and drop. Its overwritten every 15 minutes to update the data. Guess we'll have to see what we can do with the script. Appreciate the help.
Trip McLaughlin
When you publish a CSV file, via Add Item from my computer on the Content tab, you can specify the time zone your time data is collected in. The option is at the bottom of the dialog. The default value is UTC.
Have you tried changing the Time Settings under the Layers section in the overview page of your hosted feature layer? Enabling time through there should work.
Is there a way to control the time settings when loading a csv as a hosted feature layer since we are not using Pro or ArcMap to publish the service? We are also seeing a 4 hour discrepancy from the original data in the table.
Not sure about AGOL but in Portal 10.5.1 this solution is better than enabling time properties per-layer in ArcMap because that makes a time slider appear on any web map you add the service to. We can't figure out how to make that go away, even after disabling the time slider in the map document before publishing. If you just want your time to show up correctly without having to deal with time sliders, this is best. Also, the time zone property does not exist in ArcMap 10.2.1 (wasn't introduced until 10.4 as far as I can tell), so we had to publish first then change the time zone in Server Manager.
Thats a perfect and simple solution, Thanks Daniel. Much Appreciated
Helo,
i had the same problem. You can change the time zone on the arcgis server manager. Therefor you have to go to your service -> paramters. You will find an option to change the time zone for the whole service. But this only works with published services !
Adding some relevant blogs to this discussion:
Mastering the Space Time Continuum: Considerations for Publishing Date Fields to the Web | ArcGIS Blog
https://community.esri.com/community/gis/web-gis/arcgisonline/blog/2017/06/27/mastering-the-space-time-continuum-20-more-about-date-fields?sr=search&searchId=97070ff4-896e-44ab-a306-ab985835dd5c&searchIndex=1
Matt English,
Yes, Pro appears to be missing the ability to set a display time zone. So date fields from hosted layers in AGOL display in UTC time in Pro. I've passed your comment on to the Pro team so they can address this in a future release.
Thanks,
Here's a follow-along question: If I'm consuming a feature service in ArcGIS Pro that has a date/time field that's set to UTC how do I tell Pro to offset the values to my correct timezone so that they look meaningfull when I open up the Attribute Table or click on a feature and show the popup. Here's the feature service (take a look at the "Updated" field):
http://www.arcgis.com/home/item.html?id=38406bada3104e258fc8b42a2a96581a
It works as expected in the Online Map Viewer but not in Pro.
Cheers,
Matt
ArcGIS Pro supports setting a timezone at publish time that will apply to all date fields. I have the latest version of Pro (as of now, 1.4.1) but I think this was added somewhere in the 1.3.x release.
Thank you Mike! My mistake was that I was publishing map service. It worked when I published it as a feature server
Thanks
Where is this service running (hosted or your own server) and did you publish the service with the time zone set?
Without any time zone configuration, ArcGIS Online assumes all time is stored in UTC. Thus, when displayed in the Map Viewer of ArcGIS Online, time values will get adjusted based on your offset from UTC. To avoid this, you need to publish data (either hosted or to on premises portals) with the appropriate time zone or ensure time values are in UTC.
If you have published to your local server and you're consuming the service in ArcMap, ArcMap doesn't make the same assumption about the time zone and just displays the value stored without offset.
Hope this helps,
Hi Mike,
I have the same issue with time, it displays 4 hours behind in AGOL. I changed the time zone in Arc Map but it doesn't change anything in my web map. However I see the changes in map server.. Any ideas? THANK YOU!
AGOL:
Arc Map:
I found these suggestions for formatting dates to display correctly in AGOL:
Work with fields—ArcGIS Online Help | ArcGIS
To account for the UTC-to-local-time-zone conversion, here are a few tips:
I have the same problem as Wael. While your solution corrects our data for the one date field we specify in the time tab, not the other dates. We have multiple date fields in each record (5 to be exact). Is there any way to universally update the timezone for the entire layer, not just a single field? I've attached a screenshot that shows the discrepancy of the data from the database and how is displays in our Portal.
Yes, in ArcMap, you can set the time zone for the layer through the Layer Properties dialog. The dates will still display with an offset in ArcGIS Online if you are not in the same timezone the data were collected in.
Hello Mike,
I have a layer that has more than one date attribute (4 date attribute).
Is there a way to set the default timeZone for this attributes using ArcMap as you've suggested.
Thanx.
Just saw a similar post about Time issues elsewhere and thought I'd throw this out there. We had a similar problem with our Parcel data (sale dates) being shown as the wrong date and time. The fix for us was to go to ArcMap (10.2.2) to the Time tab in Layer Properties and enable Time. Select the appropriate field for your date/time value and then set your local Time Zone. Then when you publish to AGOL, you'll have the correct date and time zone.
Hope this helps.
This seems to correct the issue. Thanks.
Yes, this is the web browser shifting time from UTC. Are you 4 hours from UTC?In ArcMap, you can set the timezone for a layer from the Layer Properties dialog, Time tab.Mike
サインインしたメンバーは投稿、更新のフォローなどができます。初めてですか?無料アカウントを登録してください。
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.