BUG found for tbs:num - flotaval results are different in other locations (eg Spanish)

Hi,

I found a bug related to the converion made for tbs:num operation.
The issue is that floatval results depend on location settings.
As it, if we are in Argentina, floatval results will be "1234,45".
That kind of string representation will make Excel fail.

As it, I added the following around line 3426 of tbs_plugin_opentbs.php

                    // Floats converts to local format.
                    // Deconvert it back to US Format, the one Excel understands for source data.
                    $LocaleInfo = localeconv();
                    $floatString = $Value;
                    $floatString = str_replace($LocaleInfo["mon_thousands_sep"] , "", $floatString);
                    $floatString = str_replace($LocaleInfo["mon_decimal_point"] , ".", $floatString);
                    $Value = $floatString;

Cheers,

Gabriel

Hi Gabriel,

Thanks for your submission but the problem comes from your data which are not conventionally formated.
OpenTBS (or any general function) cannot know if your data is locally formated or not formated or even custom formated. So it assumes data are not formated. Not formated means no thousand separator and "." as decimal mark.

Oh, I undertand what you are saying.
But the issue I found that if you run the code in a environment with spanish settings ("," for decimal and "." for thousands separator) the floatval function doesn't return "." as decimal separator, but "," as it is set in the locale.

Please find the following code as a sample:
  printf("%s\n", floatval("3.14"));
  setlocale(LC_ALL,"es_ES");
  printf("%s\n", floatval("3.14"));

Find more info here also
  http://php.net/manual/en/function.floatval.php#101666

Anyway, may be the best is not to cast as float?

Thanks!

Hi,

Output functions such as echo, var_dump(), printf() are actually affected by the locale configuration. Such functions return or output strings.
Nevertheless, floatval() do return a float value, not a string value, so it simply cannot be affected by the locale.

You can see that by testing :

Result:

Well, honestly, I had a problem and got it solved using the above.
I don't know when exactly the value of the float variable is being printed (or similar), but I could bet it is being transfromed by location settings.

I will look into it and provide more detail.

In my opinion, the data you're trying to merge are in fact strings representing locally formated numbers, not primitive values.

Do you use MergeBlock() with  a PHP array or a direct SQL query ?

I used a Merge Block.

What I did to test the issue was as follows:
Merge the value in two cells: One with ope:tbsnum and the other one a plain string.
The one with the string, was fine in the excel, the other one wasn't OK: The core value of the cell had "," as a decimal separator and Excel didn't recognize it.

Isn't there any place in the code that the core value is being converted to string or injected in to the Excel file?
Those are the place where locale conversion may be undesirably aplied.

Hi Gabriel,

I think you're right. I can reproduce you're problem.
But I think the problem is not due to the float conversion but to the implicit string conversion that comes just after.

Instead of:

It should be:

This way the string conversion is not affected by the locale.
This items appears 2 time in the OpenTBS code, near from each other.

I am glad we got on the same page!
As a sidenote, do you host this on Github? If so, if in the future, I find more things to enhance, I could create a pull request.

Cheers,

Gabriel

TBS is on Sourceforge and I was thinking going to Github.