ArcGIS Pro needs product wide support for displaying time in local time when the data has a time zone defined. I have no problem with time being stored in UTC by default, but my users need to interact with that time in local time. Currently in ArcGIS Online our time is stored in UTC and when my users view or edit the time they are working with local time and the software handles converting the time zones. I know about the Preferred Time Zone setting, but for services from ArcGIS Solutions I cannot turn that on. Plus doing that way seems rather limiting. I would think having the clients handle what time zone to show the data in is more flexible.
In ArcGIS Pro we are only shown UTC time and have to remember to edit in UTC time. ArcGIS Pro needs the ability to see what time zone the data is in and then display the time to the user in local time and allow the user to edit using local time. Then ArcGIS Pro handles the time zone conversions on the backend just like ArcGIS Online does.
I was asked to create a road closure map for an event and we use the road closure solution from Esri. I got the layout setup in ArcGIS Pro but when I added a table frame all the closure times are in UTC. I can find no way to have the table show the times in local time. I went back to the web app that was used to enter the road closures and all the times are "correct" (local time).
Thanks for sharing your idea. Managing date and time data can indeed be tricky. We've recently added some new field types that might help, including:
This article contains more information about new field types and and tips for managing time data.
@EmilyGeo thank you for that information. One problem with that is we use ArcGIS Enterprise 11.5 and Timestamp Offset fields are still not supported for hosted feature services. Plus it seems like there are still Esri products that do not fully support the new data fields.
@Joshua-Young Agree. There are other Ideas around Data/Time that intersect this one.
One of mine is specifically around having the same Date/Time displayed all through Pro, AGOL, apps, etc.
@EmilyGeo - was it a decade ago that a 'dumb' date/time field was asked for so we can add date/time data and nothing in the Esri pipeline will try to interpret / UTC-shift / do anything to it?
I still feel that will be easier than this ongoing 'let's make it even more complicated but we don't have the resources to have the same maturity across our stack' all the time. Pun intended.
Jumping into this discussion. 🙂
In ArcGIS Pro 3.6, we've added support for displaying date/time values for all time-zone-aware data in the map's time zone (whether that's from services with/without Preferred TZ, or local FGDB data with a layer-defined TZ).
Quick overview of the workflow:
More detailed information is available here:
The similarly-described idea mentioned by RTPL_AU, above, has been marked as Implemented, so I am hoping the requirements listed above are also handled? Hopefully you're able to move to Pro 3.6 and try it. If it looks good, please let us know and we will close this one, too.
Thanks!
-Nathan.
We are just a small town, and all of our data is in the same time zone, so we have no need to have other times anywhere in our workflows. We utilize services for our Portal and apps, but also work with the enterprise GDB data directly in ArcGIS Pro. I believe everyone assumes it is in local time because why would they assume otherwise.
Esri's recommendation has always been to create fields using UTC and that is what all of our date/time fields and editor tracking is in. I'm trying to figure out if there is a best practice here to display all the times in local time in Portal and in ArcGIS Pro.
If the editor tracking fields are in UTC, should our services have the time zone be set to EST? Or should the new "preferred time zone" be of EST with the service time zone set to UTC?
Is there a way to set the time-zone for the layers in the database so that my users don't have to worry about it?
Hi MThompson,
Have you tried defining a Preferred Time Zone on your services? The service still stores the values in UTC but the values are sent out for display in that time zone. This does not need anything from the new "display in the Map Time Zone" capability, it's been supported for a number of releases.
Here's a support page that talks about the configuration process:
...knowledge-base/how-to-publish-a-feature-service-with-a-preferred-time--000024927
For local data (eg: file GDB), the time zone is defined with the layer (not the data), so the only way to get pre-configured time zones when adding content into a map is to open layer files (rather than using Add Data and connecting to the pure data source). Or have a workflow that opens existing maps / map files / web maps (with the properties defined), or to copy-paste layers between projects.
The (new in 3.6) option to display time-zone-aware content in the map's time zone is mostly aimed at workflows that have either data or staff in different time zones, which isn't strictly your case. It's a little bit of overkill (ie: configuring your layers and maps), but it would work to convert the displayed values so you could - for example - use it to see your Editor Tracking fields in a local time zone (eg: EST).
Thanks, -Nathan.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.