translating foreign data

[Richard Damon]

On 6/23/18 11:27 AM, Steven D'Aprano wrote:
> On Sat, 23 Jun 2018 09:42:29 -0400, Richard Damon wrote:
>
>> On 6/23/18 9:05 AM, Marko Rauhamaa wrote:
>>> Ok. Here's a value for you:
>>>
>>>     100€
>>>
>>> I see '1', '0', '0', '€'. What do you see in your locale (LC_MONETARY)?
>> If I processed that on my system I would either get $100, or an error of
>> wrong currency symbol depending on the error checking.
> Then your system is so unbelievably broken that it should be nuked from 
> orbit, just to be sure.
>
> The data you were given was 100 Euros. If your system is incapable of 
> reading that as 100 Euros, and errors out, then at least to know that it 
> is brain-damaged and useless.
>
> But if instead it silently changes the data to $100 (US dollars? 
> Australian dollars? Zimbabwe dollars? the gods only know what a system 
> that broken might do...) then it is not only broken but *dangerously* 
> broken.
>
Locale based currency transformations are defined as a number to/from a
text string.

The number CAN'T say 100 Euros (can you give me what bit pattern you
would use for such a number).
The currency is encoded in the locale used for the conversion, so if it
is using en-US, the currency value would ALWAYS be US$ (which the
general locale format is just $). As such 100€ is an invalid input to a
system getting a Locale based input for a currency if the locale is not
one from a country that uses the euro. What the input sees is '1', '0',
'0',  some funny character (or maybe 2 of them). A poorly designed
input, or one being intentionally generous on input acceptance would
return 100, which would be implied US Dollars. A better error checking
routine would give an error. It is IMPOSSIBLE for it to return a number
that would be 100 euros. I suppose a very smart system might see that it
was in a different currency and try to convert it, but unless time
reference point to use for the currency, you are likely to get a wrong
answer, but in any case, the answer will NOT be 100 euros, but some
equivalent value in Dollars.

Now, if you want to define a perhaps more general currency input routine
that tries to detect a pan-locale currency input, and returned both a
value and a currency type, that could be more useful in some contexts.
But you then run into the interesting (and difficult) problem that if
you see the input of 123.456€ what is that value, is it a value around a
hundred euros specified to 3 decimal places, or is it a number just over
100 thousand euros.
>
> [...]
>> Locale predates UCS-2, it was the early attempt to provide
>> internationalization to C code so even programmers who didn't think
>> about it could add the line setlocale(LC_ALL, "") and make their code
>> work at least mostly right in more places. A single global was quick and
>> simple, and since threads didn't exist, not an issue.
> Threads were first used in 1967, five years before C even existed.
>
> https://en.wikipedia.org/wiki/Thread_%28computing%29#History
>
Threads did NOT exist (at least to the Standard) in C when locales were
added, and the C language did nothing to support threading at that time.
Looking back, it was perhaps a regrettable decision to implement locales
globally the way there were, but it is what it is.

-- 
Richard Damon