Opened 11 years ago

Closed 10 years ago

Last modified 10 years ago

#6933 closed defect (fixed)

dojo.number.parse('09', {pattern:'0#'}) returns NaN

Reported by: guest Owned by: Adam Peller
Priority: high Milestone: 1.3
Component: Core Version: 1.1.1
Keywords: dojo number parse integer zero padded Cc: anthony.fryer@…
Blocked By: Blocking:

Description

Assuming '0#' is a valid pattern which I belive it is, shouldn't dojo.number.parse('09', {pattern:'0#'}) return 9 instead of NaN?

I think the problem is in the dojo.number._integerRegexp. I did a global replace of "(?:0|[1-9]
d*)" with "(?:[0-9]
d*)" and then the above expression worked returning 9. Not sure if this is the correct fix though. There must be a reason why you used (?:0|[1-9]
d*) in the first place but i'm not sure what it is.

Change History (6)

comment:1 Changed 11 years ago by Adam Peller

Milestone: 1.2
Owner: changed from anonymous to Adam Peller

Agreed, sounds pretty fishy. I'll take a look at it.

Only thing I can think of is that the regexp may have been used for or stolen from some other code where leading zeros weren't allowed. Seems like they should be here.

comment:2 Changed 11 years ago by Adam Peller

Milestone: 1.21.3

or just return "(?:\\d+)";

This seems like the right thing to do, especially since it format and parse should behave as inverse functions, but the unit tests based on icu4j explicitly prohibit leading zeros. I need to find out why.

comment:3 Changed 11 years ago by Adam Peller

Milestone: 1.3future

still seeking clarity on number formats.

comment:4 Changed 10 years ago by Adam Peller

Milestone: future1.3

comment:5 Changed 10 years ago by Adam Peller

Resolution: fixed
Status: newclosed

(In [15970]) Tolerate leading zeros in whole part without separators. Fixes #6933

comment:6 Changed 10 years ago by Adam Peller

I spoke to someone on ICU4J, which is where we got the tests from, and it would seem that the tests for failure on leading zeros is invalid. I'll leave the leading zero restriction in place for numbers with separators for now (e.g. 0,123.456 is not valid) though I wish this were spec'd out more clearly.

Note: See TracTickets for help on using tickets.