That’s what the second calculated field does. You would have to return a string, and then deal with it on the output as not a date. Which I suppose we could do, but it’s tough to be consistent on that and remember, “It’s a date, but we have to lie to the system and make it a string because the system is trying to be helpful like excel…”
Out of curiosity, does a function date behave same?
To clarify, it’s on the output that it get’s shifted. The input is fine.
That’s a good question. I’m not sure.
Interesting, does the problem affect inside BAQ editor or only when invoked via REST?
Edit: Well i dont guess it would\could
Only when invoked via REST, and only with V2! So not only is it wrong, it’s the worst kind of wrong where it’s inconsistent.
A nice podcast episode about why handling time sucks.
Well I wasnt much help but it was nice talking to ya, it’s been a while.
This is what I got back.
And I checked in our CR version, and it is fixed.
So that’s good news I guess. (doesn’t help us in this moment, but at least we can see light at the end of the tunnel)
That’s a train! 
More than that - OData v4, that is used in REST v2 BAQ, but not everywhere in REST v2 
It is coming from Microsoft part of the stack as ERP tables use DateTime data type only.
1 Like
Thanks for the validation @Chris_Conn
Yep that’s a killer