When you overcome the 12th day and it throws you an error, it is because in reality in that field it belongs to mes . Here is an example to understand us better:

string fecha = "10/22/2016"; // 22 Octubre 2016
Console.WriteLine("Fecha ingresada: "+fecha);
DateTime fechaFormateada = DateTime.ParseExact(fecha, "MM/dd/yyyy", null);
Console.WriteLine("Fecha con formato: "+fechaFormateada); // 2016-10-22 12:00:00 AM
Console.WriteLine("Fecha con formato corto: "+fechaFormateada.ToShortDateString()); // 2016-10-22
Console.WriteLine("Dia: " + fechaFormateada.Day); //22
Console.WriteLine("Mes: " + fechaFormateada.Month); //10
Console.WriteLine("Anio: " + fechaFormateada.Year);//2016       
Console.ReadLine();

Generating as result:

Fecha ingresada: 10/22/2016
Fecha con formato: 10/22/2016 12:00:00 AM
Fecha con formato corto: 10/22/2016
Dia: 22
Mes: 10
Anio: 2016

On the third line where the format is defined as "MM / dd / yyyy" is the format you use. For more information, check out: link

What would be the correct way to save the Date value in a database with setting in-US?

Assuming that the field in the database is of type DateTime or Date , the date format that will not give you problems to represent a date as a string in an Insert / Update statement, with SQL Server installed and configured in different languages, it is YYYYMMDD for date only and YYYYMMDD HH: MM: SS for date / time. Yes, without hyphens and with two points; I know it's weird if you have background from another database, but that's SQL Server (and I'm not going to defend it).

With this in mind, you could modify your code to this:

propertyInfo.SetValue(inputObject,  Convert.ToDateTime(propertyVal).ToString("yyyyMMdd"), null);

And in theory it should work

That said ...

Avoid using textual representations for dates, numbers, etc.

The data access interfaces of most modern languages have the ability to perform correctly the task of sending and retrieving information correctly to virtually any database engine, if you represent the data in native language formats . The authors of the drivers of the different engines have taken care of these little big details (that if the decimal point is a point, or a comma, that if the date is represented in one way or another ). In fact, many database clients will accept the binary data, which also optimizes the process time and travel through the network.

If you can, send the dates as dates, the numbers as numbers, etc. and forget about these problems forever.

Expanding the response of @jachguate, the format "yyyyMMdd" is called "unseparated string format" (UnseparatedStringFormat), this format is multilingual and independent from the established DATEFORMAT, so it does not matter what your configuration will keep correctly in the base of data.

Quote:

  

The string literal formats affect the presentation of data in user applications, but not the underlying integer storage format in SQL Server. However, SQL Server could interpret a date value in a format of the string literal, provided by an application or user for storage or a date function, as different dates. The interpretation depends on the format combination of the string literal, the data type and the run-time configuration of SET DATEFORMAT, SET LANGUAGE and the default language option.

More information: Use date and time (MSDN) data