Has anyone noticed that when you update a character field using REST, with a value that happens to be a valid ISO date string, Epicor will magically convert it to a US date, and drop the milliseconds part?
It makes sense that precision is lost when updating a date field, because the value has to be stored as such in the SQL database. But why character fields? They can and should be stored as-is.
What is the SQL field type though? Datetime?
nvarchar(max)
I see
Here’s how to reproduce:
https://SERVER/ENVIRONMENT/apps/resthelp/#/select-service/v1/methods/Ice.UD101Svc/Update.BO
Then use this input:
{
"ds": {
"UD101": [
{
"Company": "EPIC06",
"Key1": "2023-07-17T15:43:42.461Z",
"Character01": "2023-07-17T15:43:42.461Z",
"RowMod": "A"
}
]
}
}
And see this output:
{
"parameters": {
"ds": {
"UD101": [
{
"Company": "EPIC06",
"Key1": "07/17/2023 15:43:42",
"Key2": "",
"Key3": "",
"Key4": "",
"Key5": "",
"Character01": "07/17/2023 15:43:42",
Someone somewhere needs a beating.
Don’t transform my data.
What’s worse is that in this example, creating a second UD record with an ISO date that differs in milliseconds only, will cause a duplicate record error.
You’re getting Kevin revved up 
Reproduced in 2023.1.8
Ok I’ve done some testing so we can report this properly.
I added some text both before, and after (separately), and this does not occur.
Somewhere, either in the serializer or Epicor’s REST code, it must be recognizing that, when passed alone by itself, it is a date, and transforming as such. It doesn’t seem to care that it’s a string field, or that it’s wrapped in quotes.
Do any other RESTful services do that?
It’s already reported, but there was some doubt at Epicor UK support whether this is behaviour of all REST API’s.
My workaround is to replace the “T” in the ISO date with a space, making it more readable as a side effect.
You answered my question.
There is no DATE type in JSON. Dates need to be passed as strings, so must always be wrapped in quotes. It is up to the backend to interpret whether the string is representing a date or not. I suppose there is some automagic here going wrong.
Another weird thing is that the format after conversion is technically neither a US date nor a SQL date.
A US date would use a 12-hour clock and AM/PM.
The native SQL datetime format is “YYYY-MM-DD hh:mm:ss”.
Aaaaand here comes good old me, saying “I told you so!” about the benefits of strong typing in web services! Take that, REST and JSON apologists! 
But seriously, a date is just a number. Save DateTime.Ticks to the database.
Which version of Epicor are you on… I thought they had a bug in earlier versions and fixed in latest.
EDIT: Maybe I am thinking of the UTC offset bug
Kevin can you make sure you have a Format Culture set on your userid in User Maintenance. See if it produces the same.
Also make sure at the company level you have a timezone set
This could make a difference in how to interpret strings as dates. Not whether to interpret them as dates.
The Epicor database hardly has any datetime field. Everything is split into separate date and time fields. Time fields are integers or decimals that sometime represent seconds, sometimes hours. A legacy caused by the Epicor database being designed in the very old days, in a version of Progress that did not have a datetime type.
Both true but…