#1134: unexpected behavior of AgaviDecimalFormatter's thousand separators when
passing a number < 1000
-------------------------------------+--------------------------------------
Reporter: mec...@… | Owner: david
Type: task | Status: new
Priority: low | Milestone: 1.0.2
Component: util | Version: 1.0.1
Severity: normal | Keywords:
Has_patch: 0 |
-------------------------------------+--------------------------------------
Description changed by david:
Old description:
> I have done some testing with AgaviDecimalFormatter and discovered an
> unexpected behavior.
>
> Case #1: $value='9.95'; $locale=de_DE; $hasExtraChars=false;
>
> Case #2: $value='9,95'; $locale=en_US; $hasExtraChars=false;
>
> $result = AgaviDecimalFormatter::parse($value, $locale, $hasExtraChars);
>
> Result #1: $result = int(995); $hasExtraChars=false
>
> Result #2: $result = int(995); $hasExtraChars=false
>
> I expected according to the apidocs in both cases $result = int(9) and
> $hasExtraChars=true.
>
> If I am right i would recommend to fix the bug by adding a strict mode
> [1] which will set the $result to bool(false). when strict mode is
> disabled i would prefer an reparation of the $value like locale=en_US;
> $value='9,95' => $result='9,950' instead of $result='995'.
>
> another idea would be:
>
> strict=false => repair the thousand/$cents separators to get a valid
> localized number - now return the value (would help people who work both
> with 'en_*' and $other localized numbers).
>
> strict=true => see [1]
>
> i wonder how you will fix this issue if it is a bug.
New description:
I have done some testing with AgaviDecimalFormatter and discovered an
unexpected behavior.
{{{
#!php
<?php
$result = AgaviDecimalFormatter::parse($value, $locale, $hasExtraChars);
}}}
Case 1:: {{{$value='9.95'; $locale=de_DE; $hasExtraChars=false;}}}
Result 1:: {{{$result == (int)995 && $hasExtraChars == false;}}}
Case 2:: {{{$value='9,95'; $locale=en_US; $hasExtraChars=false;}}}
Result 2:: {{{$result == (int)995 && $hasExtraChars == false;}}}
I expected according to the apidocs in both cases {{{$result == (int)9}}}
and {{{$hasExtraChars == true}}}.
If I am right I would recommend to fix the bug by adding a strict mode
which will set the $result to bool(false). when strict mode is disabled I
would prefer an reparation of the $value like locale=en_US; $value='9,95'
=> $result='9,950' instead of $result='995'.
another idea would be:
strict=false => repair the thousand/$cents separators to get a valid
localized number - now return the value (would help people who work both
with 'en_*' and $other localized numbers).
strict=true => see above description
I wonder how you will fix this issue if it is a bug.
--
--
Ticket URL: <http://trac.agavi.org/ticket/1134#comment:2>
Agavi <http://www.agavi.org/>
An MVC Framework for PHP5
_______________________________________________
Agavi Tickets Mailing List
[email protected]
http://lists.agavi.org/mailman/listinfo/tickets
