I can't wrap my head around what is going on here with datetimes...
I have a hosted feature layer that is published and appears to be correctly in UTC (I did not explicitly set but the info and documentation indicates that I don't need to) which is what I want all my times to be in no matter where the user is. However, if I pull it into ArcGIS Pro, it "autocasts" +5 hrs which, if I actually wanted to autocast, is not Eastern time (my local time).
Spatially Enabled Data Frames created from querying the original UTC service return the correct date times. Then when I append those to a new hosted feature layer that should be in UTC (have tried both explicitly and implicitly setting UTC), it adds +5 hrs in Portal and if I bring it in to Pro it adds another +5 hours... both of which are going the wrong way for timezone.
Definition queries on client, DQs within View filters, and filters for applications like Ops Dashboard seem to try to use client local time as well which is not what I want when I do something like "within the last 1 day".
What I have found through my research is that this behavior of autocasting is not a bug but a feature. For me it is a massive bug that has literally no redeeming values. What do I do to make it stop autocasting?!?
Using Pro 2.8.0, Enterprise 10.9.1, arcgis python api 1.8.5. Can't ask me to upgrade, I have no control over that. Supposed to be getting Pro 3.0 but it has been unstable so IT is probably rolling back until 3.1+.
Did you try the following article: https://support.esri.com/en/Technical-Article/000015224
Thanks for the reply. The linked article only works for non-hosted feature layers but I found the issue was upstream with my data frame's timezone. Even though date time is input as UTC on the server side, it has to be explicitly set to UTC on the dataframe series otherwise the dataframe assumes local time zone.