Date labeled wrong with Arcade

[JeffThomasILM]

I keep losing a day when labeling with Arcade. I have a date field (not text) with manually entered dates, e.g., "5/1/2003". I did not enter any times. If I label it with Python by simply calling the date field, [Date], it returns exactly that date and formatting. If I call the field with Arcade, $feature.Date, it labels as: "2003-04-30T20:00:00-04:00". I figured out how to format the date: Text($feature.Date,'M/D/Y')‍, and though it's kind of annoying that that's necessary when using Arcade, I at least get it. But the head-scratcher is why I've lost a day. Note that the labeled date is 2003-04-30 (or 4/30/2003), not 5/1/2003 as it should be. I'm sure it has something to do with the time shift. But the question is, how do I prevent this from happening? Do I have to reformat my data? Seems silly that I should have to do that, but at least I'd know what to do. Or is there a way to leave the data as it is and use Arcade to re-format properly? Thanks!

[JeffThomasILM]

I figured out how to use Arcade to add time to mitigate the labeling rollback:

DateAdd($feature.Date,6,'hours')‍

Not all of my dates had the same time offset; some are 19:00:00-05:00 while some are 20:00:00-04:00. Adding 6 hours overcompensates for either. But who knows; I could encounter a 7 hour offset some day and then my DateAdd of 6 hours wouldn't be enough. Adding too many hours could push the date too far forward... it's not a universal solution. And I'm still left shaking my head that I have to worry about this at all! Still trying to understand Arcade's behavior, if anyone has any insight. Thanks!

[JeffThomasILM · Accepted solution]

Ha, just keeps getting better. Another solution is:

ToUTC($feature.Date)‍‍‍‍‍

That's a universal solution. Still wish Arcade didn't default to crazy formatting. And doesn't really answer the question: How do I stop Arcade (and other ArcGIS functions?) from time shifting my dates? Apparently it knows (or thinks it knows) what timezone I'm in? Why would I ever want my labels to be unexpectedly different from the actual data?! I understand it's great that ArcGIS can calculate things for labels or field calculations, but I don't understand why anything but a straight transfer of field values would be the default. Other side of the coin, perhaps this is an issue with the way date/time is stored and displayed in the attribute table. 

[XanderBakker]

A little background about dates in ArcGIS Online in this recent 2 minute video:

https://www.youtube.com/watch?v=v3kh_6PZEg0&feature=youtu.be

[JeffThomasILM]

Thanks for the link, Xander. Let me see if I understand. If Arc is populating a date field itself (e.g., editor tracking), it fills in the time it happened in UTC along with the offset of the time zone (it thinks) I'm located in. When that date/time is retrieved (e.g., labeling), it shows me the correct local date/time. But if I'm filling in dates manually without specifying time, Pro automatically assumes the time is 00:00:00 UTC, then subtracts (since I'm west of PM) my local time. This will always result in the prior date being retrieved/displayed. Is there a way to prevent that from happening? Basically, tell Arc to disregard time and/or time zone, and simply show the date as is?

[XanderBakker]

Hi Jeff Thomas ,

That is a good question. I can imagine that there should be some way to configure the time zone in which you will enter and visualize your data in ArcGIS Pro.

KKramer-esristaff , any suggestions?

[JeremyDavies]

Hey Jeff-- did you ever find a solution this issue of arcade shifting the day? It's driving me crazy! I tried changing the time zone on the Time tab, but that had no affect.

[JeffThomasILM]

Hi, Jeremy. The answer is yes and no. Insofar as getting it to label correctly, that can be accomplished (at least for my situation) with the ToUTC() Arcade date function:

ToUTC($feature.Date)‍‍‍

You might be facing any number of different issues; one of Arcade's date functions can probably do what you need. As for preventing the time shift to begin with, that's more complicated. You and I are hardly the first people to be frustrated with Arc's date-time behavior. Esri creates global solutions, which sometimes complicates what should be simple local issues (like what time it is?!). This thread provides some more insight: ArcGIS Online Time Zone - Over-ride UTC default? I hope you're able to find an acceptable solution!

[JeremyDavies]

Thanks for the link-- I'll read it see where it takes me! For now I am using 'ToUTC' via Arcade in the formula below, and it produces the correct day. If I learn anything more on this topic, I'll sure to share. In the meantime, your tip was a game changer for me- thanks!

YMD_Text = Text(ToUTC($feature.DateTimeStamp),'YYYY') + Text(ToUTC($feature.DateTimeStamp),'MM') + Text(ToUTC($feature.DateTimeStamp),'DD')‍

[XanderBakker]

Hi jrdavies ,

Wouldn't it be shorter to use this:

MD_Text = Text(ToUTC($feature.DateTimeStamp),'YYYYMMDD')‍