REST converting ISO dates in character fields to US dates

[pimzand (Pim Zandbergen)]

@josecgomez

You’d have to go and manually parse ir handle each date field or give it a custom date handler that would somehow know the difference between a string string and a string date lol

That should not be too hard. If you are assigning a string value, just take it as is. If you are assigning a date value, expect the input to be ISO formatted, else fail. Kinetic UI always uses ISO, and REST programmers ought to be educated.

[klincecum (Kevin Lincecum)]

Of course, if they leave it in the mode they have it now, since it IS a DateTime, they could parse it back out to an ISO string, if it was a text field, but that sounds dangerous as well as redundant. Still have to do type checking.

I really don’t understand why they are doing all this extra code anyway. They have the types defined, why not just deserialize directly to the damn things?

[pimzand (Pim Zandbergen)]

@klincecum

Of course, if they leave it in the mode they have it now, since it IS a DateTime, they could parse it back out to an ISO string,

Wouldn’t that drop the milliseconds and the timezone?

[klincecum (Kevin Lincecum)]

@pimzand

Wouldn’t that drop the milliseconds and the timezone

That’s why I said it was dangerous. You might be able to make it work, but too many moving parts.

Edit, I mean you can do this:
dt.ToString("yyyy-MM-ddTHH:mm:ss.fffZ", CultureInfo.InvariantCulture)

But what all is Newtonsoft parsing? Did it come in that way? How do we know?
So → dangerous. Might even be worse.

[pimzand (Pim Zandbergen)]

It would transform strings like 2013-07-02T09:00:00-7:00

[klincecum (Kevin Lincecum)]

You are correct that it could mangle it, but what I showed will come back out correctly for this input:

In: 2023-07-17T15:43:42.461Z
Out: 2023-07-17T15:43:42.461Z

Still very dangerous because there are a lot of unknowns though, I would not try something like that at all.

[klincecum (Kevin Lincecum)]

@josecgomez

You’d have to go and manually parse ir handle each date field or give it a custom date handler that would somehow know the difference between a string string and a string date lol

If they turned off the Date Handling, then this would fix it:

row[column] = column.DataType.Name == "DateTime" ? DateTime.Parse((string)columnValue) : columnValue;

I guess to be absolutely safe we could check the type of the incoming columnValue as well.

[klincecum (Kevin Lincecum)]

Just musing, but in upstream code, they should already be passing a JsonSerializer settings object somewhere, because I by default I believe numbers without decimals come in as longs, so how are they handling that if they try to shove it in an int field?

Will it do an implicit conversion? Questions, Questions.

[klincecum (Kevin Lincecum)]

@klincecum

so how are they handling that if they try to shove it in an int field?

Will it do an implicit conversion?

Ok, I’m answering my own question. It will do an implicit conversion and will overflow if it’s too big.

@klincecum

they should already be passing a JsonSerializer settings object somewhere

I take that back, because the Parse would ignore that too.

[kananga (John K)]

@josecgomez

After much reverse engineering and debugging it turns out it isn’t an Epicor issue its a Newtonsoft Issue

Epicor should consider a bug bounty program! And kick it off with this one.

[utaylor (Utah Taylor)]

@klincecum

Working as Designed™

love it

[kananga (John K)]

It might really be getting fixed!

Four days after pointing support to this thread and @josecgomez 's work, this has been added to my support ticket:

Development Notes 2023-07-28 09:56:07

  Development Task TASK7256570 had notes added:
Problem PRB0267943 have been updated:
PD State have been updated to: Accepted

[pimzand (Pim Zandbergen)]

I received a similar message two days ago:

2023-07-26 07:34:13 -Development Notes
Development Task TASK7262139 had notes added:
Problem PRB0269263 have been updated:
PD State have been updated to: Accepted

Note that multiple cases apparently lead to multiple problem records.

Of course this is no guarantee that it will actually be fixed nor any indication in which version.

[kananga (John K)]

@pimzand

Note that multiple cases apparently lead to multiple problem records.

Here’s hoping that doesn’t also mean multiple solutions…

@pimzand

Of course this is no guarantee that it will actually be fixed nor any indication in which version.

[klincecum (Kevin Lincecum)]

Here is the response I got today:

Kevin,
This has been logged as a bug and accepted by development. There unfortunately wasn’t a PRB associated with it so I cannot like the PRB to the case.
The dev bug is ERPS-203145. There isn’t a ETA on a fix as of yet.

[kananga (John K)]

As far as I can tell PRB0267943 is still super active and not closed out? Last update was,

Problem has been updated by: Development Notes
Problem PRB0267943 have been updated:
PD State have been updated to: In Testing

[klincecum (Kevin Lincecum)]

Kevin,
I was able to locate the PRB associated with this bug. It’s PRB0269263.
I’ve attached that to the case and since this has been accepted by development, you should see it appear in the My problems tab in EpicCare and you can follow it’s progress.

PRB0269263.

[kananga (John K)]

Hey maybe if they deploy two fixes at the same time it’ll be twice as fixed!

[klincecum (Kevin Lincecum)]

It’s related but not the same. Hopefully they are coordinating.

[pimzand (Pim Zandbergen)]

PRB0269263 state is Closed Complete