CS0003739254
It’s been ‘in queue to be reviewed by development’ since the 21st.
Thank you, I just got a response from Epicor Support showing the same status. They also provided me with PRB0267943.
We just noticed this in our 2023.1.8 Test instance. Hopefully this is resolved soon.
Damn. We also just noticed the issue in 2023.1.9. We built an external report that calls a simple BAQ using REST api v2. The dates are 4 hours earlier than they should be (UTC-4 is applied).
Current workaround is to use v1 of the REST API.
The UTC offset has been stuck to the end of local time for ages, which was also wrong but at least we could throw away everything after the “T” in the datetime string. There’s a fix in testing apparently, but we’ll have to wait and see if the fix returns appropriate values for dates and times or if we just revert to the broken state that existed before the double-broken state we have now.
Could also pass an epoch integer, if using V1 is a concern and you don’t want to have to update reports when a fix rolls out.
Nice!
I’m not sure that’s what we wanted, but at least it’s consistent?
Yeah at least that’s easily manageable. And for anyone who’s done enough coding to earn a reasonable level of cynicism about date/time handling it’s at least an immediately obvious error.
3 Likes