No, what OP is talking about is the fact that Excel formats and parses CSV files differently depending on locale settings. For example, here in mainland Europe, Excel thinks CSV files should look like this:
ColA;ColB;ColC
1,618;2,718;3,14159
And in fact, to open an "American" CSV file in Excel you either have to set Windows to American locale settings, or use the text import wizard or the "text to columns" feature. If you don't use the correct settings, Excel will not complain, but corrupt the data (sometimes subtly).
I hope you agree that it is INSANE to make a file format depend on locale settings. As someone who writes software for scientists in Europe it leads to endless confusion and annoyance.
(And even if you do everything correctly, Excel will still mangle certain CSV files, interpreting phone numbers as dates etc...)
(Once long ago in my youth, I got bitten when the quoting app I was writing worked fine on our test server, but got the day and month fields swapped on our customer's server. And that was when I learned that you shouldn't pass dates through ODBC as text strings...
SQL Server was parsing dates based on the Windows date settings. Our test server was set to the default U.S. date format but the customer's server was set to DD/MM/YY, or vice versa, I can't remember now. What made it worse was that we handed the system over early in a month, and it worked fine for over a week...)
I hope you agree that it is INSANE to make a file format depend on locale settings. As someone who writes software for scientists in Europe it leads to endless confusion and annoyance.
(And even if you do everything correctly, Excel will still mangle certain CSV files, interpreting phone numbers as dates etc...)