oh that’s NASTY!
If anyone wants to reference my own ticket it’s CS0003739254. It got escalated to management the day after its one month birthday.
edit -
oh no oh no we need to stop them before they try to parse html with regex.
oh that’s NASTY!
If anyone wants to reference my own ticket it’s CS0003739254. It got escalated to management the day after its one month birthday.
edit -
oh no oh no we need to stop them before they try to parse html with regex.
What exactly is your ticket on? This, or the offset thing?
It’s all compounding layers of the same problem. REST incorrectly modifying values into datetime values is an outcome of REST modifying anything at all instead of forwarding whatever the server gave it like a good little connector.
It’s JSON.
You’re both wrong. Deserializing without providing a type keeps it as a string.
Deserializing what?
An ISO 8601 formatted date, if you don’t provide a type in the Json Deserializer, it will be a string.
After much reverse engineering and debugging it turns out it isn’t an Epicor issue its a Newtonsoft Issue specifically if you use a JTokenReader (Epicor does) to loop through each item in the JSON DataSet and assign the like value on the other side
Here’s what Epicor Does
I wrote a simplified version of the same outside of Epicor using just C# Visual Studio
JToken jtokenValue = JToken.Parse(@"{
""ds"": {
""UD40"": [
{
""Company"": ""C001"",
""Key1"": ""2023-07-17T15:43:42.461Z"",
}
]
}
}");
var serialized = new JsonSerializer();
JTokenReader jsonReader = new JTokenReader(jtokenValue);
//Loop through token reader
while (jsonReader.Read())
{
if (jsonReader.TokenType == JsonToken.PropertyName)
{
if (jsonReader.Value.ToString() == "Key1")
{
jsonReader.Read();
Console.WriteLine(jsonReader.Value);
}
}
}
Guess what? The value of jsonReader.Value is a Fully formed (datetime) because of some "assumption’ that Newtonsoft is doing so when you assign jsonReader.value to the EpicorRow[“Key1”] C# does a ToString() on it to store as a string and thus you get a "different’ format of the value.
This of course would be nearly impossible for Epicor know ahead of time since its something that Newtonsoft decided to do on its own, it has nothing to do with REST or types it is simply the Newtonsoft library being “helpful”
You all… “we”? Owe them (Epicor… and poor poor REST) an apology now go complain to the Newtonsoft OSS team
Lookie here someone else b*tched about it
They closed the issue as “a feature not a bug”… say… do they work for support too?
The argument is that there is no standard "date’ format for JSON so THEY Newtonsoft decided that ISO is “THE” standard and you can override it with some flags but basically if it matches the format you are SOL.
I don’t think so, I don’t recall being mean to them
I love them (hire me Epicor )
A bug in an upstream library is still a bug. I’m sure they can figure out something, and it’s definitely something they need to know about.
I have already linked them to this thread, but I will add the information from your post to my case report so they can have an easier time looking.
You misspelled “feature”
However I very much like this guy’s take on it , the gist of it is, if its deserializing into a string it should remain a string, if the target is a DateTime then by all means do your magic.
Still Epicor is here without sin (in this particular issue) (ya see this @Edpicor I expect compensation
)
I don’t know whether to give you the emoji, or newtonsoft.
That’s the beauty of FLOSS go give them a PR and then you’ll fix Epicor too by version 2026🤣 (i’m not sure how often they pull new Newtonsoft I suspect … not often)
I updated my case with some of the new information and a direct link to your post @josecgomez .
I also uploaded that guy’s awesome post
You can keep discussing this among yourselves but I like what it does, I have no plans to change it, and I would do it again if give the chance.
And if you don’t like the default it is literally one line to change:
DateParseHandling.None
So, no need to wait for new Newtonsoft. It’s not going to change. But no need either to use another libeary either. Just disable DateParseHandling and do your own conversion for fields you know are dates.
Not in Newtonsoft anyway, listen to this cat:
Yes but the amount of work to parse and come up with your logic to satisfy something that is arguably easily worked around I don’t know if that’s worth the work (imo)
Well maybe Epicor is doing just that in their OData parser, and just need to copy that to their RPC parser?
C’mon Jose, take it apart…
Edit: Short Looping Gifs suck, that’s annoying.