Hello,
after reviewing the case, the Attribute's [Date] accepted data format is yyyy-MM-dd withot hour section, and the GET Customer > Attributes returns the "00:00:00.000" as wrapped by the base date-time format in the DTOs.
Since the data-class is shared among other DTOs, removing the time part would a cause a breaking change and there are other variables where the time part is in use.
Consequently, we've conveyed that to the development team if GET-Customer > Attribute[Date] field can be individually edited to exclude the time part. We will provide further updates as more information is available.
| Subject | Author | Kudos | Views | Posted | |
|---|---|---|---|---|---|
|
| 0 | 3207 | 08-09-2022 17:08 | ||
| 0 | 3185 | 14-09-2022 16:17 | |||
| 0 | 3202 | 09-09-2022 10:52 |
When retrieving a customer using the GET /customer/{customerCd} endpoint, attributes of type date are formatted as yyyy-MM-dd hh:mm:ss.fff.
Ex:
If then we pass in that value as is to the PUT /customer/{customerCd} endpoint, it returns an error 400:
It would be much more convenient if the GET endpoint returned date attributes in a format that is accepted by the PUT endpoint.
Hello,
after reviewing the case, the Attribute's [Date] accepted data format is yyyy-MM-dd withot hour section, and the GET Customer > Attributes returns the "00:00:00.000" as wrapped by the base date-time format in the DTOs.
Since the data-class is shared among other DTOs, removing the time part would a cause a breaking change and there are other variables where the time part is in use.
Consequently, we've conveyed that to the development team if GET-Customer > Attribute[Date] field can be individually edited to exclude the time part. We will provide further updates as more information is available.