>>My code does not use the XML serializer. And I cannot change the code - now - just for this case. So, I will have to find a solution still.
>>Thank you.
>
>Do you have access to the code that is doing the serialization? If yes, would you share so we can update.
>
>If you have to live with that, there is a problem, consider:
>
>01/02/2019
>
>How would that be interpreted? It is Jan 2 in USA and Feb 1 in Europe. Assuming, in such case you would favor US settings (could be instead server default), I have created a demo code for you (SQL Server 2012 and later):
>
>https://dbfiddle.uk/?rdbms=sqlserver_2017&fiddle=dda4d99a3924f79400ee650a0f822ae4

I do have the code that does "serialization." I am writing the serialization in quotes because my code does not really do it. It was "my way" of storing multiple values in the ASP.NET and passing it to the SQL Server SP.

But the key is in the SQL Server stored procedure where the value of the DateTime is extracted. This is the code (I am reposting it):

SELECT @TargetDate = [Fld FldName].value('.','char(10)') FROM @XmlDocWo.nodes('/WORK_HIS/Fld') Fld([Fld FldName]) WHERE [Fld FldName].value('@name','varchar(20)') = 'DATE_TARG'

The XML string XmlDocWo is passed to the SQL Server SP. And this XML has many purposes in the SP; so it is not so easy for me to change it. Although I admit there must be a better way to create this XML. I can't just do it "on-the-fly" since it changes a lot in many places.
Please see my reply to myself about the format of the datetime string I finally use (in the ASP.NET). For now, at least, this resolved the issue.