Enable local time formatting of UTC date/time data

3753
19
01-05-2022 02:57 PM
Status: Open
Labels (1)
AJR
by
Occasional Contributor II

It would be nice if ArcGIS Pro had a feature that allowed for the display of data stored in UTC time to be displayed in local time.  For fields (i.e. editor tracking) that are stored as UTC, having to manually do the timezone, conversion is a pain.  A way to tell ArcGIS Pro to display the UTC date/time as local time (from the machine that AGP is running on) should be relatively easy to implement but would be extremely helpful.

19 Comments
TanuHoque

Thanks @WalkerHenry__NIFCAdmin for adding your use cases.

Just to make sure I understand your workflow correctly...

to keep it simple, let's say you have two users. UserA is from Denver, CO and UserB from Portland, ME. They are adding two separate incidents within their Pro sessions. Both incidents happened exactly at 12:30pm on 4/21/2023 in their respective local time (aka wall clock time) - even though they happened 2 hrs apart.

I assume by "most all users want to be able to input dates in the local time through Pro", you were suggesting that in the above case both UserA and UserB will enter the same value i.e. "4/21/2023 12:30 pm". Since UserA is CO (that is in Mountain time zone) and UserB is in ME (in the Eastern time zone), Pro will apply the correct time difference while storing them.

Please let me know if I didn't understand your workflow.

WalkerHenry__NIFCAdmin

@TanuHoque ,

Exactly.

And when each viewed the other's record, it would show +/- 2 hours from their own.
Matching the behavior seen in AGOL.

Thanks,
Walker

GIS_Spellblade

I'd like to hop onto this idea as well. We have a similar business use-case; we keep our primary data is in UTC, per company policy, but when users input dates into our data they are not expecting to have to compensate for the UTC conversion.

This crops up in the following ways, a user will input the date an asset was created (yyyy/mm/dd) and due to their timezone differential, the asset appears to be created the previous day. This is relatively easy to compensate for in a web application through utilizing Arcade and the ToLocal() function for display. On desktop the workaround is a bit more cumbersome and would require one of the following:

  1. a field calculate snippet for desktop users
  2. an attribute rule per featureclass with manually entered dates
  3. a constant sticky-note to remind them of their time difference

All of the above options are unsavory and require varying amounts of overhead to create and maintain; hence, a software setting that abstracts this away from the user (and the program administrators) would be ideal. This would be a huge quality of life improvement for those in our organization that are responsible for data entry who are normally not the same individuals who are proficient in programming datetime conversions.

TanuHoque

first, my apologies to @WalkerHenry__NIFCAdmin for not replying before. Somehow it fell thru the cracks. 

I'm not sure if you tried this yet, we made a big enhancement to make working with date/time in Pro 3.2 and Enterprise 11.2.

Please try the new field type named esriFieldTypeTimestampOffset. That should work for your workflow

 

@GIS_Spellblade 

pls give esriFieldTypeTimestampoffset field type a try and let us know if that doesn't work for your use case.

 

I'm more than happy to answer questions regarding these new field types here.

thanks

WalkerHenry__NIFCAdmin

Thanks @TanuHoque ,

I'm anticipating the new Timestamp Offset field to meet our needs perfectly and looking forward to the Date Only field as well.

However, we need them to be implemented across Pro, AGOL, and Field Maps before we can begin any use.
Our primary editing service follows an annual cadence. Fingers crossed for 2025.

Thanks

TanuHoque

@WalkerHenry__NIFCAdmin 

I'm glad to know that. 

Pro and AGOL support these new field types. That said, the FS sync workflow (which I believe is critical for your workflow) doesn't support this yet. My understanding is that supporting these field types by both sync workflow and Field Map app is the road map for the near term.

Adding some blogs posted related to these new field types for users who will read this thread in the future.

GIS_Spellblade

I'm not sure that this solves the use-case for us. We're noticing discrepancies between the time as provided in the Editor Tracking fields vs. the manually entered fields. It is possible for us to update all of our manually entered fields but that's a bit of a lift across our entire infrastructure.

Additionally, when we're serving this data out in a web application, it seems the pop-ups are aware of the client's local time and automatically casting our UTC dates to those times (even though the service settings are set to UTC and display in UTC) which is throwing everything off. Our expectation here is that the web pop-ups would display the time as recorded within our database.

TanuHoque

@GIS_Spellblade 

Our expectation here is that the web pop-ups would display the time as recorded within our database

with recent enhancements in web app such as new Map Viewer and Experience Builder, you can set your webmap's time zone to view data in a particular time zone. By default and the way it was before is that web apps always show date/time values in your device local time zone.

ArcGIS Pro, starting either at 2.8 or 2.9, displays date/time in preferred time zone set to the service level. If there are no preferred time zone or you are using Pro version older than 2.8, you will see date/time showing up in UTC.

One option you can try for now is what we call unknown time zone. If you set your service's time zone to unknown, your date/time values will be passed around and displayed as-is.

you might find these two blogs helpful

ArcGIS Online Map Viewer supports date-time data off multiple time zones in a single layer (esri.com...

Working with Online feature service date-time attributes in non-UTC time zones in ArcGIS Pro (esri.c...

 

 

 

GIS_Spellblade

@TanuHoque, is there an Idea open for collecting Editor Tracking Information with the new UTC + TimeZone Enabled field instead of the UTC or database time?