SmartClient Version: v13.0p_2024-01-10/Enterprise Deployment (built 2024-01-10)
I am currently experiencing an issue with a RestDataSource, specifically during add/update operations involving a date field. The problem arises when attempting to parse the string value coming from the client, resulting in a validation error.
The date value causing the problem is: "2019-09-22T00:00:00+0200". This format appears valid to me, and I am confident that it was functioning correctly in the past.
Upon inspecting the DefaultValidators class, I observed that at line 1966, the parseDate method is called:

Inside this method, during the second 'if' statement (due to the length of "2019-09-22T00:00:00+0200" being 24 characters), the last character is removed, resulting in: "2019-09-22T00:00:00+020".
Subsequently, in the fifth 'if' statement (due to the updated length of 23 characters), "-0000" is appended.
The resulting string becomes "2019-09-22T00:00:00+020-0000".
Of course, this modified string fails to parse with the specified format string, "yyyy-MM-dd'T'HH:mm:ssZ".
This format string would have worked correctly with the original string value "2019-09-22T00:00:00+0200".
I am currently experiencing an issue with a RestDataSource, specifically during add/update operations involving a date field. The problem arises when attempting to parse the string value coming from the client, resulting in a validation error.
The date value causing the problem is: "2019-09-22T00:00:00+0200". This format appears valid to me, and I am confident that it was functioning correctly in the past.
Upon inspecting the DefaultValidators class, I observed that at line 1966, the parseDate method is called:
Inside this method, during the second 'if' statement (due to the length of "2019-09-22T00:00:00+0200" being 24 characters), the last character is removed, resulting in: "2019-09-22T00:00:00+020".
Subsequently, in the fifth 'if' statement (due to the updated length of 23 characters), "-0000" is appended.
The resulting string becomes "2019-09-22T00:00:00+020-0000".
Of course, this modified string fails to parse with the specified format string, "yyyy-MM-dd'T'HH:mm:ssZ".
This format string would have worked correctly with the original string value "2019-09-22T00:00:00+0200".
Comment