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
... View more