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.

Sign up for GitHub

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

Jump to bottom

Universal parsing for locale-formatted strings #56

Open
awilkins opened this issue Feb 6, 2015 · 1 comment
Open

Universal parsing for locale-formatted strings #56

awilkins opened this issue Feb 6, 2015 · 1 comment

Comments

@awilkins
Copy link
Collaborator

awilkins commented Feb 6, 2015

As brought up in #55 there are a number of places in the code where locale-formatted strings are being parsed or checked with code that assumes the decimal separator is a dot. Some locales use a comma.

This code needs reviewing and fixing.
@awilkins awilkins self-assigned this Feb 6, 2015
@awilkins awilkins mentioned this issue Feb 6, 2015
Open
awilkins pushed a commit that referenced this issue Feb 6, 2015
Parse all potentially locale-formatted floating point numbers with lo…
8cf8c72 
…cale-aware parser

Fixes #56

Where the UI code parses floating point numbers it was generally using
Float.parseFloat() and Float.valueOf() ; these methods are convenient
but use FloatingDecimal.readJavaFormatString() which only works on the
anglocentric standard Java float string format.

At least one place in the UI formats floats using the user locale!

This means round-trips where the UI was generating strings that
could not be validated because they didn't use the dot as their
decimal separator.

Took all instances of these methods out of the UI parsing code
and replaced them with NumberFormat.parse() instead.

This affects

* QueryField
* DurationEditor
* EstimatedEditor
* TimeEntryEditorPart
awilkins pushed a commit that referenced this issue Feb 11, 2015
Patch another instance of trying to use the universal Float format
8e836db 
Yet another place where a localised format may get passed to
the code.

fixes #56
@awilkins
Copy link
Collaborator Author

Please note that I don't presently have the time to do a systematic review of this, but I do think one is needed.

Essentially

  • All locations where there is a floating point integer string presented to the user should be written and parsed in the user locale
  • All other locations where a floating point integer string is processed should use the universal format (dot)

@awilkins awilkins removed their assignment Sep 16, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@awilkins