Time zone toggle in ArcGIS Pro
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:
- 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.
Tanu
@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:
