There seems to be a bug in the system time string (only 24h format):

The command GUI.getDisplayTime() will return a string, as it is shown in the display.

The command
GUI.getDisplayTime().substring(0,2)
returns the first two digits as a string.

If you want to convert this string to an interger the command
parseInt(GUI.getDisplayTime().substring(0,2))
will return
6 at 06:xx
7 at 07:xx
0 at 08:xx (which is not correct)
0 at 09:xx (which is not correct)
10 at 10:xx

As a workaround, the command
parseInt(GUI.getDisplayTime().substring(2,1))
returns always the correct second digit.

I used:
PEP2 newest release
Newest Firmware
9600 and 9400 same behaviour

This has nothing to do with GUI.getDisplayTime(); the following:

parseInt("08");

will also return 0.

What happens is that parseInt will treat a string with a leading zero as an octal value; you need to force it to interpret the string as a decimal integer:

parseInt("08", 10);

will return 8.

thx sogliphy,

obviously my javascript experience is to improve.
Didn't remember that parseInt is also converting formats.

There's also a quick way to extract time that also handles either 12hr or 24hr format using RegExp. I posted this method quite a long time ago.

[Link: remotecentral.com]

You can check ampm for non-null and not empty string and if this holds true, you can bet the remote is set for 24 hour format.

In the case of 24 hour clock, hour === 0 is midnight and hour===12 is noon.

You should be able to work out other details but RegExp is my preferred approach to all this string parsing. With one fell swoop, you can get hour, minute and ampm (if a 12 hour clock).

parseInt always converts formats -even for decimal numbers-, it interprets a text string as a number, using a number format which is either auto-detected or specified explicitly, into an internal representation for a number.

For example,

var text = "1020304050607080901";
System.print(text);
System.print(parseInt(text));

results in:

1020304050607080901
1020304050607081000

The first line is the original text string.

The second line is the result of converting the original text string (ending in "0901"), to the internal number representation, and converting that back to a decimal string representation of the number. The amount of significant digits in the decimal number in the text string is too large to fit in JavaScript's internal representation, so there is some loss of accuracy.

Nice catch. Yes, parseInt implies that you are parsing 32 bits and will adhere to that. However, var x = Number("1020304050607080901") should work.

System.print(new Number("1020304050607080901"));

also yields 1020304050607081000.

The JavaScript internal number representation, as defined by section 8.5 of the ECMA-262 edition 3 standard, is not able to represent integers larger than 9007199254740992 without losing precision.