Skip to content
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

Parsing always uses target currency NumberFormatInfo #28

Closed
GoogleCodeExporter opened this issue Mar 18, 2015 · 3 comments

Comments

@GoogleCodeExporter
Copy link

commented Mar 18, 2015

What steps will reproduce the problem?

1. Execute the following code in an en-US or en-GB context. 
2. Console.WriteLine(Money.Parse("€1000.00", Currency.Eur));


What is the expected output? What do you see instead?

The output is "100.000,00 €". This is partially understandable but also 
confusing. It is understandable insofar as Eurozone countries tend to use the 
period/full-stop as the thousands separator and the comma as the decimal 
separator. However, it is confusing in that the code is running in a culture 
context that reverses these symbols. I would *not* argue for a change in the 
current behaviour, but an ability to provide a NumberFormatInfo to use when 
parsing the decimal portion would be good. See below for an example 
implementation.


What version of the product are you using? On what operating system?
Version 3.5.1.0 on Windows 8.1 Update 1, .NET 4.5.


Please provide any additional information below.
Attached is a modification of Money.Parsing.cs file to add a new overload 
taking NumberFormatInfo. I would very much like for this to be merged into the 
code base. I assign the copyright to the copyright owner of the existing file, 
provide no warranty as to its usage, etc. etc.!


Original issue reported on code.google.com by joshua.p...@googlemail.com on 7 Aug 2014 at 10:21

Attachments:

@GoogleCodeExporter

This comment has been minimized.

Copy link
Author

commented Mar 18, 2015

I will look into it.

Thanks for the report and the "patch".

Original comment by danielgo...@gmail.com on 1 Sep 2014 at 1:57

  • Changed state: Accepted
  • Added labels: Milestone-Release3.5.2
@GoogleCodeExporter

This comment has been minimized.

Copy link
Author

commented Mar 18, 2015

Hi Joshua,

I have been looking into the issue you mention and the code you supplied.
The code looks sensible and I am sure it solves a concrete problem you are 
facing. However, it opens some questions:
* parsing is a feature I am not too proud of (as it delegates entirely to the 
esoteric and brittle implementation of System.Decimal) and I would use with 
caution
* The example you propose (Euro) is probably the worst case scenario, as there 
are just so different ways to represent it: different patterns, negative 
symbols and separators.
* A string with a different symbol from the format parsing makes parsing fail, 
but a different separator yields unexpected values
* The caller of the new method would be passing two possibly "contradicting" 
ways of interpreting (parsing) the string: the NumberFormatInfo instance and 
the currency instance. I agree that, in this overload, the NumberFormatInfo 
should drive the parsing, but I not sure that the symbol should be the only 
"contribution" from the currency.

Having thought it through your solution is good enough given the number of 
possibilities and the inner workings of decimal.Parse() and it will be part of 
the API.

Original comment by danielgo...@gmail.com on 8 Sep 2014 at 11:58

@GoogleCodeExporter

This comment has been minimized.

Copy link
Author

commented Mar 18, 2015

Original comment by danielgo...@gmail.com on 8 Jan 2015 at 7:16

  • Changed state: Fixed
  • Added labels: Milestone-Release3.6.0
  • Removed labels: Milestone-Release3.5.2
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.