android - System.currentTimeMillis() does not work as expected

Question

I use System.currentTimeMillis() to save the time a user starts an activity.

public class TimeStamp {
protected long _startTimeMillis = System.currentTimeMillis();

public String getStartTime() {
    return new Time(_startTimeMillis).toString();
}

the class is instantiated when activity is started and getStartTime() returns the correct time. I also try to get the time that has passed after the activity has been started.

public String getElapsedTime() {
    return new Time(System.currentTimeMillis() - _startTimeMillis).toString();
}

This works perfectly fine using an emulated android device (android 4.0.3). But when I deploy the application on my real android device (android 4.0.3) getElapsedTime() starts with one additional hour and then counts up normally. So on my real device getElapsedTime() will return "01:00:01" after the activity was started, but it should return "00:00:01".

Do you have any ideas why this happens?

Why you are creating new Time()? again? just long should be enough right? — kosa, Aug 14 '12 at 14:52
I use new Time() for converting the long in a human readable string. — Jens Ehrlich, Aug 14 '12 at 14:59
your problem seems formatting related so solutions probably here: http://stackoverflow.com/questions/266825/how-to-format-a-duration-in-java-e-g-format-hmmss — zapl, Aug 14 '12 at 15:27

score 13 · Accepted Answer · edited Aug 07 '15 at 08:39

13

You should use SystemClock.uptimeMillis().

uptimeMillis() is counted in milliseconds since the system was booted and is guaranteed to be monotonic whereas System.currentTimeMillis() isn't because the user or an application can change it at any time. Also, usually automatic time synchronization is enabled which can change the time at any time.

edited Aug 07 '15 at 08:39

nhaarman

98,571
55
246
278

answered Aug 14 '12 at 14:52

tolgap

9,629
10
51
65

SystemClock.upTimeMillis() and SystemClock.elapsedRealtime() are better methods for time measurment but the main-problem was the formatting – Jens Ehrlich Aug 14 '12 at 22:02
How this could help if scenario like "user start level at SystemClock.upTimeMillis() then restart the system and finishes the level at SystemClock.upTimeMillis()". I doubt this method/function doesn't work right? – kiranking Feb 25 '19 at 19:43

score 1 · Answer 2 · answered Aug 14 '12 at 15:00

1

You can't use Time to represent a difference between 2 instants. In your code, getElapsedTime() returns a time close to 0, which is interpreted as 1970, January 1st. I think that the reason why you have a problem is because you don't have the same time zone on your device, hence the origin of time is not midnight.

answered Aug 14 '12 at 15:00

Laurent Perrin

14,671
5
50
49

thanks for the answer, when I start the activity I save the time since 1970, January 1st in milliseconds as _startTime. When I wait 10 seconds, 10,000 milliseconds passes. So a System.getcurrentMillis() after 10 seconds should return _startTime + 10,000. Both System.getcurrentMillis() are called in the same time-zone, so this should not matter? – Jens Ehrlich Aug 14 '12 at 15:12
If you make 2 calls separated by 1s, you will get Time(1000). This equals jan 1970, midnight + 1s **GMT**. But if the system's time zone is not GMT, then you'll get something else. – Laurent Perrin Aug 14 '12 at 18:08
Long story short, you shouldn't use Time to manipulate time differences. It's only made for absolute times. – Laurent Perrin Aug 14 '12 at 18:10

score 0 · Answer 3 · answered Aug 14 '12 at 14:58

0

System.currentTimeMillis() returns milliseconds passed between the device's clock time and the epoch date. That's why it can vary from device to device.

http://developer.android.com/reference/java/lang/System.html#currentTimeMillis()

answered Aug 14 '12 at 14:58

Shivan Dragon

15,004
9
62
103

android - System.currentTimeMillis() does not work as expected

3 Answers3