Time Zone is incorrect when overwriting existing Feature Services

[tigerwoulds]

I have around 30 Feature Services published from a SQL Server 2019 EGDB to Enterprise 1071 from Pro 2.7. I was asked to track the date and time when edits are made - simple enough I stopped the services and enabled editor tracking on the feature classes in Pro. 

I am overwriting the services and during the publishing process, changing the Time Zone configuration from UTC to Central Standard and adjusting for daylight savings. After publishing, records are still being collected in UTC time. Server Manager shows the Time Zone correctly. Any ideas what's going on here? 

Thanks

[AngusHooper1]

What is the system locale time for the various VMs that support Portal, hosting server etc?

[tigerwoulds]

GIS Server (hosting Server) and Portal are in the desired Time Zone - Central Standard.

[GaryMacDougall]

Hi

I am assuming you are working with a feature service that references your enterprise geodatabase data (not a hosted feature service ) - correct?

In order to record the editor tracking values in database time, you need to configure it to record dates in database time when enabling editor tracking. See: https://desktop.arcgis.com/en/arcmap/10.3/tools/data-management-toolbox/enable-editor-tracking.htm

That said, it is recommended you record the dates in UTC as it is more efficient for services workflows.

thanks

Gary

[tigerwoulds]

I found that if I run the Enable Editor Tracking tool and create the required fields + specify Database Time, it still collects in UTC. Very annoying workaround but I did figure out a solution. I need to Enable Editor Tracking via right click (this will create the fields and default to UTC time) > Run the Disable Editor Tracking tool > Run the Enable Editor Tracking GP Tool, specify the already created fields and database time > Delete the existing REST Service > Publish a new service and set the time zone to CST and adjust for daylight savings. 

Overwriting the existing service even after enabling editor tracking this way does not work, still collects in UTC time. Filed a case with esri about this. 

[garymacdougallesri]

Hi

One thing to try here is to stop the service, re-enable editor tracking with database time and then restart the service. This should pick the changes. One question here, are you using shared mode or dedicated mode?

thanks

Gary

[tigerwoulds]

Tried that but unfortunately does not pick up the time zone in CST this way, still reverts to UTC even though Database time is set in during editor tracking and while overwriting the service. We are using dedicated instances - there is a known bug with 1071 and schema updates not working with services using Shared Instances. 

[garymacdougallesri]

Thanks - will check in to the case once it is filed and submitted