REST converting ISO dates in character fields to US dates

Kinetic ERP
21

That used to be the way for Microsoft to serialize dates to JSON, until they conformed to ISO 8601.

1 Like
22

Yes but Epicor is Epicor… if you look at their OData DataWriter under the microscope you will see it doing stuff like:

if (culture != null) {
    newDate = dt.ToString(request.culture.DateTimeFormat.ShortDatePattern);
}
else
{
    newDate = dt.ToString("s");
}

But if you confirmed then its probably somewhere else, something else :slight_smile:

Good question for @Olga and @josecgomez how come Epicor is transforming nvarchars/strings

1 Like
23

We need a laughing popcorn emoji.

101094704-popcorn-happy-fast-food-concept

On second thought, maybe not, that’s oddly terrifying.

1 Like
24

Following, had this after BST kicked in.

I had a scenario were a UBAQ in a dashboard kept subtracting a date by a day were the time element was midnight.

25

I think we covered that in these two threads:

1 Like
26

It happens in Kinetic UI too!
That makes sense, as Kinetic UI is built on REST.

Just enter 2023-07-17T15:43:42.461Z in any description, address or whatever field, save, and refresh.

1 Like
27

It does not happen in the Classic Client.

Kinetic:
bugg

It definitely is in the Write because when I refresh the Classic Client:

image
image726×594 16.4 KB

1 Like
28

Have not tried Kinetic UI in the smart client yet, just the browser.

30

That looks more like the response than the request.

31

I am definitely seeing the original value in the request, using Firefox Web Developer Tools.

1 Like
32

Postman would beg to differ :slight_smile:

1 Like
33

Damn devs and their Easter eggs! Not so fond of this one :rofl:

Happy Easter Eggs GIF by Lisa Vertudaches

Working as Designed™

1 Like
34

Just when I found the perfect format to use as part numbers…

35

I take that back it is before it hits a BPM, not necessarily the client. Long Day.

1 Like
36

Just store them backwards:
Z164.24:34:51T71-70-3202

37

I was just going to try how Epicor reacts to reverse ISO dates.
I was expecting “Paul is dead”.

38

That’s what ISO 8601 is for. REST is definitely converting from the type it’s given to another representation - given a SQL date it turns that into a UTC datetimeoffset without actually converting to UTC time rather than being a good little connector and returning the closest available representation (a naive calendar date). That’s the way it’s always been broken, but now the offset bug adds an unfortunate new layer of compunding oops.

The worrying part about this one is that @klincecum 's example is Z-format UTC datetime instead of a timezoneoffset. Inconsistent REST configurations in the wild rule out straightforward fixes.

39

Try this one: Z000.00:00:00T90-11-6691

40

My point is that there is no way to tell whether a JSON element is a date by looking at the syntax. You need to know it represents a date, or guess it by examining the value. And it looks like guessing is taking place.

1 Like
41

Whatever they’ve done, they’re gonna need to patch this. Parsing dates should not be done until the type is known to be a date.

1 Like