I think this is 100% true.
Sometimes I want a column to say [Input Date of Arrival] other times I want it to say [Arrival Date] other times I want it to say [Date Inputted By User Upon Receiving the Package]. It depends on who my audience is.
If the data input user is looking at it, it’s probably [Input Date of Arrival], when the dashboard user looks at it it’s [Arrival Date], and when I’m looking at it on the backend I want [Date Inputted By User Upon Receiving the Package].
I may have multiple different measures of “arrival date”, a
RowModified(thisRow.[Item Status]), one that is sent to me by Amazon through Zapier, and one that is logged by the user. All of those measure information that could easily be called “Arrival Date” from a frontend users perspective, and in different cases they would be perfectly meaningful to a user given their context.
As a final example. If you order a package and it says, “Arrival Date” next to a date in the future, you know that’s the date it will arrive. On the other hand, if you are looking at an inventory log and there’s a column that says, “Arrival Date” you know that’s the date it did arrive. But, importantly, “Date it Will Arrive” and “Date it Did Arrive” are often not the same (due to delays or inventory issues) and therefore represent the opposite case: multiple different columns that could have he same display name.