Time zone toggle in ArcGIS Pro

11-16-2018 09:40 AM
New Contributor III

If this older idea cannot be implemented: Option to not use UTC time offset in ArcGIS Online 

Could we instead have the option to set ArcGIS Pro to display time in UTC, rather than in the local time zone of the machine it is running on?

The use case that prompts this request is as follows: an organization has some users with Pro, and many more users who only use ArcGIS Online. These AGOL-only users sometimes create new hosted feature services with time fields. It is not feasible for them to publish these feature services from Pro or ArcMap (which I understand would allow them to  associate the local time zone with these feature services). However, when Pro users then interact with those feature services in Pro, time is displayed in the local time; similarly, if Pro users add features, those features' time attributes are added in local time and so display the "wrong" time in AGOL.

As we are trying to use AGOL + Pro for event management, the four/five hour difference between UTC (displayed on AGOL) and Eastern Time (displayed in Pro) is a potential cause for major confusion. It doesn't matter much to us whether the data is actually stored in UTC or not, but it matters that everyone working on this data see the same event occurring at the same hour, regardless of whether they view it via Pro or via AGOL. 


Currently, it is not possible to display UTC dates in a local time zone when working with a time enabled ArcGIS Online Hosted Feature Layer in ArcGIS Pro. This functionality should be enabled. 

Status changed to: In Product Plan

Hi MTaft, 

In the next release of Pro we will consume a new service property for a 'preferred time zone' that will be available in next releases of ArcGIS Online and Enterprise. This preferred time zone is what Pro will use to display your data, as a service owner/admin you will be able to set this property to whatever time zone you want to use to work with your data. We hope to build on this functionality in subsequent releases.


by Anonymous User

Using ArcGIS Pro v2.6.3 and ArcGIS Online.

We have noticed that, when updating date fields, the raw date that ends up stored in the feature service is different depending on whether the method used to enter the date was Pro vs other applications.

When we update a date using the standard ArcGIS Online map viewer or Collector, the datetime picked will be in our local timezone (happens to be Auckland, NZ) and the date is converted and stored in UTC time (currently 13 hours behind) which, to us, is correct and is what we expect.

However, if the same datetime is entered via Pro, this is stored directly as-is into the database. Meaning the stored date, when compared to the other UTC times, is 13 hours ahead of what it should be.

The answer according to several blogs and Geonet posts appeared to be to set a timezone when publishing the feature service. We tried this by publishing a new test service, but it made no difference.


To try and understand this, we examined the REST endpoint JSON and observed that the feature service had the following set in the service definition:

  "dateFieldsTimeReference" : {
    "timeZone" : "UTC", 
    "respectsDaylightSaving" : false

This seemed unusual, since we had specifically set a timezone in Pro before publishing. We tested publishing several more feature services, sometimes specifying a timezone and/or different timezones and with daylight savings ticked/unticked, but every time the JSON says the timezone was UTC and respectsDaylightSaving was false.

We then tried manually updating the service definition using the admin rest endpoint. We weren't able to find any documentation about what values should be set in place of "UTC", but we at least tried setting "respectsDaylightSaving" to true. No error message was reported when updating the definition, but when we examined the JSON of the service definition afterwards, it was still set to false, so nothing had actually updated.

In summary, currently whenever we enter a date using Pro, it ends up 13 hours out. The only workaround is to tell users not to update the dates in Pro, or else manually enter a time 13 hours in the past. Publishing with a timezone either does not work, or we are misunderstanding how it works.

Does anyone have any suggestions?





Thanks @RussellBrennan.



In addition to what Russell mentioned, if I may I'd like to add that we understand there are a lot of issues our users have been facing when it comes to date-time values. As you know working with date/time especially when it comes to time zones is a big pain in general.


Here is one thing I'd like to clarify:

when Pro users then interact with those feature services in Pro, time is displayed in the local time;

Technically, unlike MapViewer (or JS API), ArcGIS Pro, as of v2.6, does not do any time zone conversion while consuming date/time values from a feature service. It assumes date/times are coming in UTC and it displays them in UTC. The reason it assumes 'date/times are in UTC' is because as per ArcGIS REST API specifications, map/feature service query operations always returns date/time in epoch (UTC).

Same thing happens while editing - Pro assumes an editor enters date/times in UTC and submits that as UTC. When someone enters date/time in local time zone, you will see incorrect data.

If you open a feature service layer's Property page, switch to the Time tab and scroll down a bit, you will see the Time Zone is set to UTC for that layer.



Finally I have a question for you:

  1. Do you store event date/times from different time zones in a single feature service? Or you maintain one feature service storing only data from a single time zone?

I'd appreciate if you kindly explain a bit more on your use case. May be sample data that you might share with us?


Thanks a lot.



Great to hear this will be resolved soon!

@TanuHoque I haven't tested this in v2.6, the post was made well before 2.6 existed. If 2.6 does no time zone conversion that would be totally fine for our purposes.

We do not store events from different time zones in a single feature service, no. Our event information is local to our one campus, perhaps at most to the state of MA. I don't foresee a need to (ever?) cross time zones for these purposes.


I haven't tested this in v2.6, the post was made well before 2.6 existed.

I meant to say that it has been like that, I think, since the beginning. There was nothing new done in 2.6 in this area.


As Russell mentioned that the new enhancements coming up in next Pro release (fingers crossed).


@TanuHoque That is not what I am seeing in 2.6.2

Here is an example feature service in Pro: 


Same service in AGOL:



Honestly I don't know which timestamp is correct (aka reflects the time the editor would have seen on his computer's clock when he did the edits). I believe it's probably the AGOL time. It doesn't really matter-- what matters is that they are being displayed differently in AGOL/browser vs Pro.

Its properties show that its time zone is UTC:




Sorry for the delay, and as it appears I couldn't make it clear.

What you described in your last comment is how Pro behaves. And we realized that creates a lot of confusion.

As I mentioned:

  • ArcGIS Online Feature Services store date/time in UTC
  • Feature Services return date/time in UTC
  • ArcGIS Pro displays date/time values in UTC
  • When you visualize the same feature service in MapViewer (or AGOL) in a web browser, the  date/time values are displayed in your device's local time zone, NOT in UTC.
    • Since  you are in MA, date/time values are displayed in EDT when viewed in AGOL map viewer - which are 4 hours (or 5 depending on day light saving) behind UTC.
  • Since AGOL and Pro are showing date/times in two different time zones you are seeing the discrepancies. It creates confusions, and potentially corrupts data when an editor enters date/time values in local time zone instead of UTC in Pro.


With release of ArcGIS Pro 2.7 and AGOL Dec release, this discrepancy should go away albeit not by default. You need to opt into that mode. The reason we will ask users to opt into is because if we change the default behavior, it could potentially break a lot of users' current workflows.

Please let me know if you have any question.


hi @Anonymous User,

I just merged your Geonet question titled "Can't publish feature service with timezone" to this post as it appears to me that you are running into the same problem that is being discussed here.

Please read previous responses and let me know if you have any question or I misunderstood your question.