Decimal to string conversion ignores system locale #6021

New Issue

admin · 2026-01-22T15:24:54+01:00

admin commented

2026-01-22 15:24:54 +01:00

Originally created by @flaushi on GitHub (Jul 17, 2018).

Originally assigned to: @Ocramius on GitHub.

Q	A
doctrine/annotations	v1.6.0 MIT
doctrine/cache	v1.7.1 MIT
doctrine/collections	v1.5.0 MIT
doctrine/common	v2.8.1 MIT
doctrine/dbal	v2.7.1 MIT
doctrine/doctrine-bundle	1.9.1 MIT
doctrine/doctrine-cache-bundle	1.3.3 MIT
doctrine/doctrine-migrations-bundle	v1.3.1 MIT
doctrine/inflector	v1.3.0 MIT
doctrine/instantiator	1.1.0 MIT
doctrine/lexer	v1.0.1 MIT
doctrine/migrations	v1.8.1 MIT
doctrine/orm	v2.6.1 MIT

Support Question

I have to make sure to handle decimals correctly. I have an Entity with decimal type member.

When assigning 1234.56 to it, after fetching the object, the value is the string "1234.56", so no thousands-separator and . as decimal separator. The system locale is de so the locale aware string should be "1.234,56".

Can I rely on this locale-unaware return value? Can you point me to the source code where it happens, I can't find it.

I also posed this question in SO, but got no answer so far.

Thanks in advance!

Originally created by @flaushi on GitHub (Jul 17, 2018). Originally assigned to: @Ocramius on GitHub.  | Q | A |------------ | ----- doctrine/annotations | v1.6.0 MIT doctrine/cache | v1.7.1 MIT doctrine/collections | v1.5.0 MIT doctrine/common | v2.8.1 MIT doctrine/dbal | v2.7.1 MIT doctrine/doctrine-bundle | 1.9.1 MIT doctrine/doctrine-cache-bundle| 1.3.3 MIT doctrine/doctrine-migrations-bundle| v1.3.1 MIT doctrine/inflector | v1.3.0 MIT doctrine/instantiator | 1.1.0 MIT doctrine/lexer | v1.0.1 MIT doctrine/migrations | v1.8.1 MIT doctrine/orm | v2.6.1 MIT ### Support Question I have to make sure to handle decimals correctly. I have an Entity with `decimal` type member. When assigning 1234.56 to it, after fetching the object, the value is the string "1234.56", so *no* thousands-separator and `.` as decimal separator. The system locale is `de` so the locale aware string should be "1.234,56". Can I rely on this locale-unaware return value? Can you point me to the source code where it happens, I can't find it. I also posed this question in [SO](https://stackoverflow.com/questions/51264406/doctrines-decimal-type-conversion-to-string-locale-aware), but got no answer so far. Thanks in advance!

admin added the Question label 2026-01-22 15:24:54 +01:00

admin closed this issue

2026-01-22 15:24:54 +01:00

admin commented

2026-01-22 15:24:56 +01:00

@Ocramius commented on GitHub (Jul 17, 2018):

1.234,56 is NOT a valid number. Yes, it is in DE, but not for computer systems.

Type conversions in DBAL only convert via type casts, nothing locale-aware.

See 5405427568/lib/Doctrine/DBAL/Types/IntegerType.php (L52-L55)

@Ocramius commented on GitHub (Jul 17, 2018): `1.234,56` is NOT a valid number. Yes, it is in DE, but not for computer systems. Type conversions in DBAL only convert via type casts, nothing locale-aware. See https://github.com/doctrine/dbal/blob/54054275689c9b9759bd607f6d0cf63c77d52375/lib/Doctrine/DBAL/Types/IntegerType.php#L52-L55

admin commented

2026-01-22 15:24:56 +01:00

@flaushi commented on GitHub (Jul 17, 2018):

Thanks! For integers, everything is clear. For floats/decimals its diffferent. Looking at 5405427568/lib/Doctrine/DBAL/Types/DecimalType.php (L52), I see no conversion/casting being performed. Does this mean, that the result depends on what is returned from the database? The database however does not return a string...

@flaushi commented on GitHub (Jul 17, 2018): Thanks! For integers, everything is clear. For floats/decimals its diffferent. Looking at https://github.com/doctrine/dbal/blob/54054275689c9b9759bd607f6d0cf63c77d52375/lib/Doctrine/DBAL/Types/DecimalType.php#L52, I see **no** conversion/casting being performed. Does this mean, that the result depends on what is returned from the database? The database however does not return a string...

admin commented

2026-01-22 15:24:56 +01:00

@Ocramius commented on GitHub (Jul 17, 2018):

Decimal types are supposed to be kept as string to avoid type juggling errors.

@Ocramius commented on GitHub (Jul 17, 2018): Decimal types are supposed to be kept as `string` to avoid type juggling errors.

admin commented

2026-01-22 15:24:56 +01:00

@flaushi commented on GitHub (Jul 17, 2018):

So, then floatval is the correct way to get the corresponding float, independently of any locale? This makes things easier. I was just afraid that switching to another DB layer any time in future might break this rule and lead to errors then.

@flaushi commented on GitHub (Jul 17, 2018): So, then `floatval` is the correct way to get the corresponding float, independently of any locale? This makes things easier. I was just afraid that switching to another DB layer any time in future might break this rule and lead to errors then.

admin commented

2026-01-22 15:24:57 +01:00

@Ocramius commented on GitHub (Jul 17, 2018):

@flaushi yes, this is supposed to be locale-safe. Strongly advise against (float)-ing a numeric field though: use something like ext-bcmath to ensure that operations make sense at the end of the day, and that you don't have an IEEE-754 rounding error.

@Ocramius commented on GitHub (Jul 17, 2018): @flaushi yes, this is supposed to be locale-safe. Strongly advise against `(float)`-ing a `numeric` field though: use something like `ext-bcmath` to ensure that operations make sense at the end of the day, and that you don't have an IEEE-754 rounding error.

admin commented

2026-01-22 15:24:57 +01:00

@flaushi commented on GitHub (Jul 17, 2018):

Thats a good catch, thank you. Issue can be closed

@flaushi commented on GitHub (Jul 17, 2018): Thats a good catch, thank you. Issue can be closed

admin referenced this issue

2026-01-22 16:05:31 +01:00

[PR #6022] Add `EntityManagerInterface` type hint to the `EntityRepository` constructor #9821

Sign in to join this conversation.