## Description

## Steps to Reproduce

On an Istanbul instance in sys.scripts.do run the following with the scope choice set to 'global':

var number = '000000020920051';

gs.info('Number parsed without radix/base: ' + parseInt(number));

gs.info('Number parsed as octal: ' + parseInt(number,8));

gs.info('Number parsed as decimal: ' + parseInt(number,10));

the output is:

*** Script: Number parsed without radix/base: 16

*** Script: Number parsed as octal: 16

*** Script: Number parsed as decimal: 20920051

The number is interpreted as octal and converted to 16 (everything from the 9 onwards is ignored as 9 isn't valid in octal).

Switching the scope to 'sn_devstudio' (uses ES5 Standards Mode) the output is:

sn_devstudio: Number parsed without radix/base: 20920051

sn_devstudio: Number parsed as octal: 16

sn_devstudio: Number parsed as decimal: 20920051

Note the difference in the first result - the leading 0s have been ignored by parseInt and the decimal value has been returned.

Repeat the same test on Jakarta through to London and the results are:

global:

*** Script: Number parsed without radix/base: 16

*** Script: Number parsed as octal: 16

*** Script: Number parsed as decimal: 20920051

sn_devstudio:

sn_devstudio: Number parsed without radix/base: 16

sn_devstudio: Number parsed as octal: 16

sn_devstudio: Number parsed as decimal: 20920051

Note that the results are identical to each other and the leading 0s have resulted in the number being interpreted as octal in both cases.

## Workaround

The workaround is to specify the radix/base when using parseInt, therefore if the value being converted needs to be interpreted as a decimal then instead of:

parseInt(number);

use:

parseInt(number,10);

This problem has been fixed in Madrid release. If you are able to upgrade, review the **Fixed In** or **Intended Fix Version** fields to determine whether any versions have a planned or permanent fix.

**Related Problem: PRB1300391**