Editor Tracking Time values calculating wrong times in UTC

398
5
07-29-2019 10:11 AM
Highlighted
New Contributor II

I am investigating an issue on a table in the database_name registered geo-database (archiving enabled) used as the datastore for a registered feature service and am hoping that the community might be able to help or have any ideas.  The table name is [database_name].[sde].[feature_class].

 

The issue we’re running into is that the created_date and last_edited_date fields are storing date values that are 4 hours in the future, beyond UTC time, which is already 4 hours in the future based on eastern time.  They’re not storing UTC values, which is what we’d expect.  What is interesting is that the GDB_FROM_DATE and GDB_TO_DATE fields are recording the correct UTC values and since these values are ESRI constructs, I'd expect those to calculate/pull time references from the same location on the same machine. Additionally, fetching UTC time at the database level also yields the correct time which lends itself to the theory that this specific to Editor Tracking fields. 

See screenshot below.  For the highlighted record, I created/edited it around 12:10 Eastern, which is 16:10 in UTC.  The GDB_FROM/TO dates correctly show 16:10.  But then the created_date and last_edited_date fields show an additional 4 hours added on:

 Discrepancy between archiving times and editor tracking times

Some additional notes on testing. 

1. In an edit session in ArcMap on ProClient01, manually adding points in a map session through a direct database connection in ArcMap yielded incorrect time in database record (no ArcGIS Server interaction). Editor Tracking is improperly adding an additional 4 hours from local time to UTC conversion (+8 for eastern).
2. For reference, GDB_TO and GDB_FROM date times are correct (ESRI Archiving fields), which helps support this is specific to the Editor Tracking fields.
3. When editor tracking is disabled and re-enabled through the “Enable Editor Tracking” geoprocessing task, if database time is specified (I believe this was in the “record_dates_in” optional choice), we get the expected time stored in UTC in the record. This yields the expected time but is different workflow than any other environment we have worked in to my knowledge. In other ArcGIS Server/Portal environments, we've never had to specify database time. We want time to be recorded in UTC since data is collected across many time zones. 

We’re wondering if something like this is happening: the registered geo-database is storing everything in UTC by default, but somewhere along the way the Esri Editor Tracking functionality thinks the database is in Eastern Time zone, so it’s adding an additional 4 hours onto the time being saved to the database.  We still don’t really know when in the workflow the additional 4 hours is getting applied, but we were able to rule out ArcGIS Server due to (1) above.

Reply
0 Kudos
5 Replies
Highlighted
Occasional Contributor III

Have you contacted Esri Support Service. If not, please do so, analyst can test and analyze the issue. 

Thanks,

Biraja

Reply
0 Kudos
Highlighted
New Contributor II

Thanks Biraja, I have a ticket in now.

Reply
0 Kudos
Highlighted
New Contributor

Were you able to track down the cause of this problem?

Reply
0 Kudos
Highlighted
New Contributor

I am encountering the same issue as well with a feature class that has archiving turned on and editing tracker UTC turned on.  I get different timestamps based on how the features are edited as well.

- edit in Portal, created_date and GDB_FROM_DATE are 4 hours different

- edit in ArcMap, created_date and GDB_FROM_DATE are 2 hours different 

Were you able to resolve this?

Reply
0 Kudos
Highlighted
New Contributor

We were missing the UTC_branch_util package in our Oracle database, causing all editor tracking date-time fields to display as 12:00AM.

Erica

This communication is subject to the Municipal Freedom of Information and Protection of Privacy Act (Ontario) and/or Personal Health Information Protection Act (Ontario). This communication may be confidential. Unauthorized use is strictly prohibited. If you are not the intended recipient, please delete this email immediately.

Reply
0 Kudos