Date Values in BAQ Results via REST API

Kinetic ERP
,
1

As of version 2023.1.6, I am seeing a change in the way dates are returned via the REST API, compared to past versions. It has broken our software integrations that rely on BAQs.

For example, I have a BAQ that I am running in versions 2022.2.12 and 2023.1.6. The BAQ returns at least one date field.

The actual date value from the database is ‘2023-05-17’.

Value Returned from BAQ via REST API

2022.2.12: “2023-05-17T00:00:00-05:00”

2023.1.6: “2023-05-16T19:00:00-05:00”

The above example is a Clock-In date from a Labor Header record. If I call the LaborSvc directly and retrieve a Labor Header record, the date values are the same in both versions.

This looks like some mis-handling of local/UTC times. Can anyone confirm that this is happening in your system as well?

We are about to upgrade to 2023.1.6 over the holiday weekend and this is a deal breaker. Not sure if I can remedy this. Any ideas?

2

It is a real bug. We tested it here.

If you can use the varchar and make it a date after that could be a workaround.

3

To be specific, you’ll have to read the thread, that statement quoted that I made was partially incorrect.

4

I got a call from Epicor Support. They are aware of the issue and development is researching it.

Currently only v2 of the REST API is affected, so a workaround would be to call v1 of the API.

This is OK for external integrations, but I’m not sure if API calls internally (like in App Studio) can be helped.

5

May be able to fudge it with a function call. :thinking:

6

If true then only mostly! The issue is that the API appears to be handling the variety of date/time datatypes with a one size fits all method that (incorrectly) casts values to a fully qualified datetimeoffset value. Any workaround that fudges the offset would likely not fix any values that shows up with an offset.

Not that BAQ technically allows datetimeoffset as a type now, but if the API continues to support timezone offsets after a fix then BAQ must support timezone offsets. Ideally API would stick as close as possible to the datatype it receives, because date/time type casts are :dumpster_fire: at the best of times much less running unattended on arbitrary BAQ’s.

Can confirm, this works! This will entirely avoid the API issue and won’t be broken by a bug fix. I have a couple of trello integrations that are extremely fortunately not broken right now, because I had some random premonition 2 years ago to handle converting datetimes to ISO 8601 string in BAQ’s.