Changes to time zone info? (Appending to feature service from ArcPro)

[NickDierks1]

I published a hosted feature service of code violations and, after a few days and lots of reading, managed to figure out how to get the time conversions between Mountain and UTC lined up so that the correct dates were displayed. My workflow has been to add new records to a local geodatabase (because that preserves the subtype-based default values), and then append them to the hosted feature service. Doing so automatically added 6 hours to the date, and there were no issues with the incorrect date displaying in the webmap popup.

Now, when I append, no hours are being added, meaning all dates are being entered as 12:00 AM, so that when the webmap subtracts 6 hours to display in my local time zone, it's the wrong date again.

Did something get changed to the way DateTime fields are handled when features are appended to a hosted feature service? This worked just fine up until recently. I tried updating ArcGIS Pro, but that didn't change anything.

[NickDierks1]

Any ideas on what's going on? Whenever I append to the feature service, the datetime fields stay exactly the same, when previously they added the appropriate number of hours to convert to UTC. I can work around this in a couple ways--manually adding the 6 hours when I initially enter the data, or using the field calculator to do it--but since there are up to 7 datetime fields for each feature, I'd really like to get back to the previous workflow where it automatically converted.

I set the time zone correctly when I initially published the feature service (and, as stated, it worked just fine for the better part of a month); I can't think of anything I did to trigger a change in behaviour.

[KellyGerrow]

Hey Nick,

Is the data that you are appending in local time or UTC?

When you published your original dataset, did you publish from ArcGIS Pro or ArcMap? If so, did you set a time zone or manually modify the date/time into UTC.

Here is a blog about dealing with time on the web. Looks like I should add an append section also.

https://www.esri.com/arcgis-blog/products/arcgis-online/sharing-collaboration/mastering-the-space-ti... 

-Kelly

[NickDierks1]

Everything was done via ArcGIS Pro. The FGDB was built, populated (using local time), and published from there. I believe it was actually the blog you linked to that clued me in to setting the time zone at the time of publishing (I hadn't on my first attempt, and noticed the time/date issues the blog discusses soon after).

The offline FGDB was never time-enabled, but as I understand it, it's still treated as residing in the time zone of my local machine (it's not on a server anywhere). For a few weeks, my workflow of adding data to the FGDB and then appending to the published feature service worked just fine. Date fields are populated without specified times--as I'm entering data on a new feature each date field shows a time of 12:00 AM until I press Enter or save my edits, at which point it shows only the date I entered. When appended to the hosted feature service, the dates all showed up as the date plus several hours, resulting in a display of 12:00am when viewing the data in a web map from this time zone. A couple weeks ago, that just stopped, and now any date that's appended retains the same time stamp without calculation, resulting in an incorrect time date/time displayed in the web map.

I'm sure I've got something completely backwards here, but I'm still not sure why the workflow worked fine for a while and then stopped.

Because the web map needs to run several Arcade calculations based on the various dates, I can't simply switch to using text fields for these, can I? Otherwise, I really only need the dates for this data, and not the times.

[EricKriener]

did you ever put up something about appending and honoring time settings? I'm running into the same problem here that I have the time zone and DST settings set when published the feature service, but when appending data, it changes everything b/c of UTC. super frustrating/maddening/unnecessary...

[BrittanyBurson]

Hi @KellyGerrow yes, it would be great if you added an Append section to your blog.

In our case we are using 10.8.1 Enterprise and publishing a hosted feature table, setting the time zone to Pacific Time with daylight savings.

The date/times on the initial table are correct.

However, when we go to append records via Model Builder, they are appending in UTC time, which subtracts 7 or 8 hours from the date and causes the date to shift backwards in time by 1 day.

Do you have any suggestions?

Thank you.

[ecmason]

Hi Brittany,

I'm facing a similar issue currently and wondered if you had found a solution?

I published a feature layer to AGOL from Pro 2.8.3, and specified the time zone to EST with daylight savings. It publishes correctly, but then when I use the "Append" tool in AGOL, to add data from an excel sheet it accepts the time field correctly. However, the date field converts from EST to UTC  which changes the date to a day earlier.

Excel spreadsheet with correct date

AGOL data with incorrect date 

Were you able to find a solution for this?

Thanks!

Liz

[RyanBohan]

Hi @ecmason,

My suggestion is to have two date fields (local time) and (UTC)

It's a little clunky as AGOL and Portal converts on the fly.  The initial data can have it's time zone set when publishing, however the append tool ignores that setting.  (my guess is the date is converted to UTC when published)

It also depends what environment your viewing the data in.  The two images below are the same published table with two date fields (UTC and local time)

First open in AGOL or Portal the UTC field is correct and the sweep_date (local time) is incorrect.

Second the AGOL / Portal table pulled into ArcPro, now the UTC field is incorrect and the sweep_date (local time) is correct.

If the data will only be viewed in AGOL / Portal use the "Convert Time Zone" tool to convert the time from local time to UTC.  Then use the Append Tool to add it to the AGOL /  Portal layer 

If the data may be used in both AGOL / Portal and ArcPro have two date fields to avoid confusion.

Hope this helps.