fixes formatting and parsing of numbers #396
Conversation
andekande
commented
Sep 13, 2013
andekande
commented
- negative numbers were not detected
- String.format is non existent
- considers culture settings on Number parsing (here in germany 9,41 should not be parsed to 9)
- exponential formatting was missing culture awareness
| @@ -47,6 +47,12 @@ function parseNumber(s) { | |||
| if (!s || !s.length) { | |||
| return 0; | |||
| } | |||
|
|
|||
| if (ss.culture.current.nf.gs.length) | |||
There was a problem hiding this comment.
The parse functions aren't yet setup for globalization (unlike the format functions). The intent here was to only parse per the invariant/neutral culture.
There was a problem hiding this comment.
Yeah, I was thinking to introduce a parseNumber(culture, s) but as you said, would be inconsistent to parseDate where culture awarenes is much more challenging. Nevertheless when coming from .Net one expects parsing to be culture aware, which in case of Numbers is easy to achieve. So I thought I would implement a robust way in the framework, rather to writing my own convert logic.
There was a problem hiding this comment.
Hum, I overcame a situation where forcibly parsing with currentCulture is not desireable:
jQuery.Select("#ID").GetCSS("font-size") => may return "22.5pt"
With my addition parseNumber("22.5pt") gets 225.
So I'll better keep my own version of culture aware parsing in my utils.
short version of: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/round eg: rounding of 1.0005 with precision of 3 is different in IE than in Chrome string res = string.Format(CultureInfo.CurrentCulture, "{0:3}", 1.0005);
