System.getTimer() Functionality Details

The API docs for Sytem.getTimer() are pretty useless:

Use getTimer() to get the current millisecond timer.

Returns:
(Number) — System millisecond timer


In using the Timer for my stop watch widget, some things I need to know (especially for the FR920XT):

1) Does the timer always start at 0 when the device is turned on?
2) Does the timer overflow?
In other words, is there ever a time when a successive call to System.getTimer() returns a smaller number?
a) If it does overflow, what is the boundary (32-bit or 64-bit)?
b) If it does overflow, what is the new starting value of the timer--0 or largest negative 32-bit/64-bit number?


You might ask why I'd care about this. The issue is that if the timer is only 32-bits, that's less than 25 days in milliseconds and it is very possible a person could have their device on for 25 days or more without turning it off. In that case, a 32-bit timer could overflow while doing timing and over that 25 day boundary.


BTW, why in the world is this method called 'getTimer()' vs getTimerTime()? It returns a time, not a Timer object. I found the name very confusing.
  • Former Member
    Former Member over 9 years ago
    The API docs for Sytem.getTimer() are pretty useless:

    Use getTimer() to get the current millisecond timer.

    Returns:
    (Number) — System millisecond timer


    In using the Timer for my stop watch widget, some things I need to know (especially for the FR920XT):

    1) Does the timer always start at 0 when the device is turned on?
    2) Does the timer overflow?
    In other words, is there ever a time when a successive call to System.getTimer() returns a smaller number?
    a) If it does overflow, what is the boundary (32-bit or 64-bit)?
    b) If it does overflow, what is the new starting value of the timer--0 or largest negative 32-bit/64-bit number?


    You might ask why I'd care about this. The issue is that if the timer is only 32-bits, that's less than 25 days in milliseconds and it is very possible a person could have their device on for 25 days or more without turning it off. In that case, a 32-bit timer could overflow while doing timing and over that 25 day boundary.


    BTW, why in the world is this method called 'getTimer()' vs getTimerTime()? It returns a time, not a Timer object. I found the name very confusing.


    1) It does but I can't really say it is guaranteed to. This probably isn't relevant to ConnectIQ apps though.
    2) Yes. I am not sure how this answer could be no. I guess if it was a 64 bit value the answer would effectively be no, but still technically yes.

    a) The API returns a Number, which is a 32bit signed int, so it would overflow on a 32-bit boundary.
    b) Internally this is an unsigned integer, so when it gets interpreted as a signed integer by ConnectIQ, you will see it overflow from MAX_SINT32 to MIN_SINT32 and then continue counting up towards the max.

    This is all pretty much irrelevant because you just need to subtract the initial value from the current value, and all the rolling over will automatically work itself out.

    The only time you would need to worry about any of these things would be timing across runs of the app (since the timer is not guaranteed to be continuous across runs), and if you are timing for more than ~25 days. For those types of things, you would need to incorporate time of day into your timing.
  • Thanks for your quick answers!

    I assume you meant "does" vs "doesn't" for your answer to number 1?

    My timer is persistent and can continue to "run" across exiting and entering the widget and can even handle turning the device off and on. However, I do want to gracefully handle timer 25 day limit boundary and not just blow up or show a negative time.
  • One other quick question-you mention constants MAX_SINT32 and MIN_SINT32. Are these actually defined in the API or were you using them as abstractions? I checked Lang and Number and didn't find any limit constants.
  • Former Member
    Former Member over 9 years ago
    I assume you meant "does" vs "doesn't" for your answer to number 1?


    Yeah, whoops, fixed it.
  • Former Member
    Former Member over 9 years ago
    One other quick question-you mention constants MAX_SINT32 and MIN_SINT32. Are these actually defined in the API or were you using them as abstractions? I checked Lang and Number and didn't find any limit constants.


    There isn't anything defined in the API.

    the max sint32 = 0x7FFFFFFF (2147483647), and the min sint32 = 0x80000000 (–2147483648)