ArcGIS Online Time Zone - Over-ride UTC default?

[AllenScully]

Any way to get ArcGIS Online to stop using UTC and use your organizations local time?

We have several maps in AGOL that use a filter on a date/time field, displaying incidents for a specific day.  However, records for a given day (July 20 for example) actually show up as July 19 in AGOL, with no records returned, even though there were in fact incidents on the 20th. 

We are not able to modify the date properties in ArcMap or database side of things as far as time zone changes.  It is and has to remain in our local time. 

I understand why AGO does this, but it drives me crazy and would love it if someone had a workaround they could share. Hopefully it's easy/obvious and I have just missed it.

Thanks -

Allen

[SimonLiu1]

It's almost 2020 and ESRI still hasn't fixed this? The date filter should be dependent on the set time zone.

I figured changing the time zone in the REST service parameters would fix the date filter problem but all it does is change the visual of the timestamp in the pop ups and attribute table but the date filter is still filtering by UTC.

And to reply to the "Correct Answer" if someone outside my time zone were to look at our applications I would expect them to understand that because we're on the East Coast that 3pm is 3pm EST not 3pm Tokyo, Japan. But all in all our applications are mostly propriety and internal staff view them. They could care less about UTC time.

Has anyone found a real solution to the date filters? I'm hesitant to offset my time to UTC because even if I can use smoke and mirrors to show EST time on the front end if someone were to access the data from the back end it could be confusing to them.

EDIT:

A Solution

My work around trying to avoid creating a custom widget (won't handle TIME but will handle DATE for the filter) was...

*Our DATE column has both date and time. This is all done on Oracle. Can work with SQL server, etc; your syntax may differ.

1) Create a duplicate column of the date column, name it date_UTC or the like

   - If your original DATE column has time, truncate the date column to only be date. No time.

   - ex) trunc(original_date)

2) Depending on UTC's offset from your local time zone add a time that will handle the offset (I did 8am, don't forget to account for day light savings).

   - ex) (trunc(original_date) + 8/24) AS date_UTC

3) On your REST service make sure you set the time zone to your local time zone so your original date column shows the correct time.

   - You can set your time zone when publishing the service in Paramters > Advanced but this doesn't work for me. I have to change it in Portal Manager.

4) in Web Map, configure the pop up of your layer. Hide date_UTC and DO NOT SHOW time in the parameters. If you don't it will show in the filter. The timestamp in your filter will confuse users.

5) in WAB when you configure your date filter, use date_UTC. 

WAB filter will now correctly handle dates (because it's in UTC). Users will be non the wiser as they'll only see the original date column in pop ups or in the attribute table.

Two cons:

1) What if a user wants to filter by a time range within a day? they can't in this scenario.

2) Someone looks at the data from the back end (through Oracle or ArcCatalog). They'll see a date column in UTC time zone but it's not real timestamps, they're all 8am in my case.

[Anonymous User]

This is like the inability to create groups in a web map - An incomprehensible limitation. The times that I want to display are very specific to a time and place. Everyone on the project knows this, and no one EVER would want them to be adjusted. They are in Montana, and the workers work roughly from 8:00 am to 5:00 or later in the evening. Seeing a time of 2:00 am will only cause confusion to anyone checking the site, whether they're checking it from Montana or China or wherever. These dates need to be "sticky."

We need a "Date" field because we need date functionality. Creating a text field doesn't help us. Creating a new field with UTC times adds complexity we don't need to data that is updated frequently.

Setting the time zone for a layer in ArcGIS Pro before publishing it as a feature service makes it unusable by Operations Dashboard. I've tested many times. Sometimes, the difference in time changes the actual date from, say September 12 to September 13, which can be a disaster when checking daily progress on a busy project.

This has been a very frustrating issue. I hope some solution is found soon.

Randy McGregor

[Michael_Knapp]

Hi - I'd like to add information as well.  This is a broader issue than just hosted data in ArcGIS online.  At this point the forced UTC time is causing huge issues for us across the ESRI platform.  We use ArcGIS online for public use and mobile editing but store our data in our own sql databases in local time and publish the service in local time.  We also use ArcGIS Enterprise portal for editing.   The user experience because of the development around the date/time (there appears to be disconnects between the app and the geodatabase and services development) is that they select a date in the ArcGIS enterprise editing against our editing service for the date of burial.  The date actually is CHANGED by the application and it stores a different date than the user has selected in the database. 

For example, we use this for our cemetery and it has resulted in a different date of death than the user entered..  So for example in the portal web editing, the user sees 9/20/1962 for date of death, but the database stores 9/21/1962 in the date of death field.

We have followed all the information and recommendations for publishing out in the local time zone and it has worked in previous versions.  No it is not a reasonable solution to just "switch" the date/time of the database server to UTC time - that is a large change with lots of impacts and as a local government organization.  It is also not a reasonable recommendation to ask that each date field have two fields - one with local and one with UTC and we are supposed to script that translation - that is a huge overhead.

For our organization, this erodes trust in the ESRI platform - we absolutely do not want the platform changing the authoritative entry that is happening.  It is a very serious issue to have an application actually change the information that is being entered.

From a quality and protection of data in an asset this needs to be addressed by ESRI.  The solution of asking clients to just use UTC time is unreasonable.  The solution of the application actually changing the data that is entered is downright scary from a protection of data perspective.  At this point the date fields are not usable for us and we are looking at other (all bad) options.

[JulianInskip1]

I was also having this issue. When publishing to on-premise Enterprise everything was ok but to AGOL the time was using UTC (as documented).

Instead of adding new fields and re-calculating dates to be UTC, you can use your local timezone fields. When publishing to AGOL, in the Configure Parameters window, set you timezone there. The rest will be handled correctly with your local datetime fields.

Have a look at this:

Work with date fields—ArcGIS Online Help | Documentation 

and this:

Mastering the Space Time Continuum: Considerations for Publishing Date Fields to the Web (Rule #4).

Please note that if you overwrite your hosted feature layer you must set this everytime.

[DentonCountyGIS]

One other issue I've observed is that if I add an item in AGOL with a mmm yyyy field (eg, a text field "Apr 2020") - or really any version of month and year that AGOL recognizes as a date - I get an offset too. In my specific case, I'm pulling in a Google Sheet, but I've had the same issues described by others when publishing MXDs; moving to ArcGIS Pro and doing time correction there was the easiest workaround we found for items we published.

Back to my cloud example (I haven't tested this when publishing from Pro/MXDs), a value of "Apr 2020" always becomes 3/31/2020, 7:00 PM even if I select central time zone (-6), keep the default UTC, or even Fiji (+12) in the add item from cloud wizard. If the data is 1/1/2020 or "Jan 2020", it then becomes counted as 12/31/2019.

I am forced to add a field in AGOL, and perform a field calculation using the Arcade expression ToUTC() to get it back to normal, my time zone. So the AGOL-forced "3/31/2020, 7:00 PM" becomes "4/1/2020, 12:00 AM". For those worried about daylight savings, it takes that into account, so the correct date still shows after the fix.

If I am pulling monthly data from another source within AGOL as 1/2019, it would be great to have the option to bring the date as-is, and for it not to become 12/31/2018 hh:mm

[GregHorne]

We are in CST and I can confirm that in Pro 2.6 that picking CST or UTC or +6 always results in 5 hours being subtracted from the date.  The option of picking a time zone appears to work IF you are copying all of the data up to the server which is not what we need to do.

[BrittanyBurson]

This. I posted here about seeing your described behavior still in ArcPro 2.8.x. Not sure how to proceed.

[LindsayMaier]

"Please note that if you overwrite your hosted feature layer you must set this everytime." 

Unfortunately, this isn't even close to a solution. For those of us who overwrite our layers outside of ArcPro using Python, this doesn't work. The time zone set gets overwritten with UTC when the Python script runs the overwrite, and as far as I can tell, there is no way to set the time zone in the ArcPy FeatureSharingDraft class.

[DavidPike]

Rule #3: When entering a date field, a default time of 12:00 am is entered when a time is not specified.

There seemed to be a suggestion this could be overcome using publishing options for a hosted feature service, that doesnt seem to be the case for an ArcGIS server feature service on Portal (please show the light if i'm wrong).

Currently users are inputting a date only, which takes the current UK time back an hour to UTC, and subsequently 11pm the previous day.

Is there any workaround other than correcting the times post-edit?  

Cheers

[RyanBohan]

I wish there was a way to turn off the automatic time conversions for a layer/table. 

I work for a city, so everything is recorded in local time, and users assume when viewing that it's displaying local time.  Unless we label something as UTC

I understand I can set the time when publishing.  However if I append data to that set, there is no option adjust the time.  Which results in date/time in the same column in two different time zones.  Clearly that is problematic.

The only work around I can find, is to have two columns, one in local time (PST) and the other in UTC.  Letting the user pick which they want to display