Sweet summer child, isn't that what people say these days?
I and you can agree that the reasonable thing to do is to accept American encoding.
(The below is somewhat simplified, the way I remember it on a late Saturday night 10+ years later.)
The outsourced team of programmers from our software vendor did not. They (mostly) used the built in regional settings in Windows (best practice, don't reinvent the wheel) meaning we had to come up with ways to make sure the machines ran with wrong regional settings (since a lot of stuff was already serialized that way && critical parts of the software was hardcoded to use US standard.)
Not sure about CSV files, but every time I'm pasting numbers generated by Python or Java I had to use Notepad or Excel itself to replace dots to commas because of (Windows'!) regional settings.
In a somebody sent this input to my program context, designing some means to choose between these three results (or possibly others) is the main concern. Actual parsing is the easy part.
Do you get the user to choose? Great, now the UI is 2x more complex.
Do you just go with what the browser or client locale says? (User lives in Canada but their laptop is set to Turkish locale).
Go with the locale tied to the geo location of the user instead? (User above stubbornly enters all amounts using Norwegian conventions after completing high school in Norway).
If it's important, a confirmation page presented to the user and formatted in their presumed locale can help a lot.
