>>>>>>>>I found the solution. Instead of using .ToShortDateString() on the ASP.NET side, I have to use a specific format:
>>>>>>>>
>>>>>>>>

>>>>>>>>TargetDate.Date.ToString("yyyy-MM-dd HH:mm:ss");
>>>>>>>>

>>>>>>>>
>>>>>>>>The above works for both the American date and the British Date.
>>>>>>>
>>>>>>>This is the format I have been saying since the beginning :) So you had access to the code, good.
>>>>>>
>>>>>>Yes, I wrote all the bad code :) I just didn't know how to set the string to the correct format. As I said, it was working for years with the .ToShortDateString() (here in is the USA). The customer in Europe exposed the "hole" in my code and I had to change it.
>>>>>>Thank you for bringing it up to my attention.
>>>>>
>>>>>BTW since you are not really using time:
>>>>>
>>>>>

TargetDate.Date.ToString("yyyyMMdd");

>>>>>
>>>>>Note: No dash or other separator in between. Otherwise it fails under some versions with specific language settings (like TURKISH).
>>>>
>>>>You maybe right. But in my SQL Server SP code I am converting this string to a DateTime type (code I wrote in another message). So, I am concerned that if I don't add the time portion (which is not used), the value of the variable will be set correctly. So far, in my testing, the string with dashes and the time work.
>>>>But if it starts causing problems, I will change it.
>>>
>>>OK I repeat, don't add separators. Time part is up to you. I wouldn't wait for it to cause troubles when there is a safe version exists.
>>
>>When I remove the separators (that is, using "yyyyMMdd"), I get error again. When I have separators, no error.
>>I think it all comes back to how I use this field in the SQL server SP.
>
>Removing separators you get error just because you are forcing the result to be char(10), right?

I know you don't like to chaise links. But if you just look into this thread on stackoverflow, it uses the separators:
https://stackoverflow.com/questions/22477356/convert-datetime-to-string-yyyy-mm-dd