After altering the session on the client side to nls_territory=America, values with "." as decimal delimiter were loaded successfully, e.g.
"92.00"^^http://www.w3.org/2001/XMLSchema#float

However, we still struggle to load triples with timezone indicator. Could anybody suggest proper way of tackling this problem. Take into account also that later we might have to incrementally add timevalues formatted according to different locales.

On investigation, rather than a bug it appears to be a case of inadequate documentation. If the way we support data from multiple locales does not address the needs of some applications we would like to get feedback about that.

(1) The timestamp issue: Timestamp with zone information is not supported in 10g release 2 (and has been documented in section 1.2.3.1 of the 10g release 2 documentation). Based on feedback from customers we have included support for timezones in the next database release expected later this year (that release is currently in beta). Could you write to me at melliyal <dot> annamalai <at> oracle <dot> com? We can explore options such as a patch depending on your timeline.

(2) Representation of numeric values in the data should follow the character set specified in the client locale. If the language is 'Finnish', then the data should be represented as "92,00"^^http://www.w3.org/2001/XMLSchema#float . If the language specified by the client locale is American then the data should be represented as "92.00"^^http://www.w3.org/2001/XMLSchema#float .

If data is inserted with mixed locales, they are stored internally as equal (because of the support for canonical data values). But when they are retrieved (and they will be in their original form when retrieved) and processed using an arithmetic operator such as '+', the current client locale comes into play - which can be one or the other, but not both. So the operation fails when the data is mixed. Data stored as 92,00 will need the client locale to be Finnish so that arithmetic operator can be applied, and data stored as 92.00 will require the client locale to be American.

So the main question is - do you have a need to mix data from different locales?

If you can write to me at melliyal <dot> annamalai <at> oracle <dot> com we can discuss more. We are also very interested in understanding the application more.