-
Notifications
You must be signed in to change notification settings - Fork 623
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
trimTrailingZeros should be an option #31
Comments
@jayd3e what about using the StringFixed instead? edit: Is it just for aesthetics or you genuinely have a use case where it does make sense to keep the zeros? |
I just ran into this issue again today due to this commit. Yeah, I really don't think it's the job of the library to make these kinds of decisions on precision. If I enter "100.00" into a decimal type, I expect to get "100.00" back out again. It's deceiving to have the precision changed by the library. This is especially true when you are putting the value into the database and retrieving it again. You want the decimal value to be exactly the same as what you entered into the database, but under the current system, it is being changed. Thanks in advance for the thought that is put into this. |
Right now it's assumed that trailing zeros should be removed upon a call to
Value
, as a decimal is being serialized into the database. This doesn't take into account cases where you want to keep the number of decimal places consistent across the board. For example, if I created aDecimal
via:I would expect it to enter the database as "100.00". When in actuality, the trailing zeros are removed and "100" is saved. This creates some interesting scenarios when storing and retrieving decimals from the database. I would expect the precedent to be that decimals are represented as a string in exactly the same way they were created, unless the user does an operation that would change the precision(such as using
StringFixed
).The text was updated successfully, but these errors were encountered: