How could SystemClock.uptimeMillis() ever wrap?

Question

The Android docs on uptimeMillis() says:

Returns milliseconds since boot, not counting time spent in deep sleep. Note: This value may get reset occasionally (before it would otherwise wrap around).

It seems quite strange that the docs are worried about it ever wrapping around. After all, the method returns a long. A quick calculation yields that it would take approximately 292,271,023 years for it to ever wrap!!!

So what's up with the docs? Is it really ever possible for it to wrap? Can the value perhaps wrap before it reaches the max value for a long? Is that what the docs are actually trying to say? And if so, when would it wrap?

---

[It's especially puzzling as System.currentTimeMillis() is also a long that represents time since an epoch. Yet, Android makes absolutely no mention of the possibility of the value wrapping. All the more so, for uptimeMillis which starts at 0...]

Duntson

As a point of interest: SystemClock.elapsedRealtimeNanos() does not have any special notes... – Dike

Answer 1

This is mainly conjecture but seems to make sense based on the docs I've found. If we take account that native public static long uptimeMillis() in SystemClock is a native method, running in 32-bit space, and then it's simply being cast to a Java long when you call it then it makes sense because 2^32 milliseconds is very easily reachable.

Felipe

32-bit space does not mean you can't return a long with a range greater than 2^32.. – Rarefaction