System.currentTimeMillis() is giving wrong time.
It returns time values from 1980
Also time value taken through this function differs from actual time sometimes.
Some sample values returned by the function
315977198121
315965244789
316002166580
315982533137
Yes, time returned by System.currentTimeMillis() can jump around, for example because the device clock may have drifted, and is being reset due to fetching an accurate time from the network
Time as observed through other APIs may also jump around even more, for example due to changing time zones, or due to daylight saving.
(However that doesn't explain why you are seeing times suddenly in the 1980. That frankly sounds like a device error.)
You state that you are using the value to get a duration. That's an error - you should be using SystemClock.elapsedRealtime() for duration calculations.
See the docs at SystemClock, which specifically note:
Three different clocks are available, and they should not be confused:
System.currentTimeMillis() is the standard "wall" clock (time and date) expressing milliseconds since the epoch. The wall clock can be set by the user or the phone network (see setCurrentTimeMillis(long)), so the time may jump backwards or forwards unpredictably. This clock should only be used when correspondence with real-world dates and times is important, such as in a calendar or alarm clock application. Interval or elapsed time measurements should use a different clock. If you are using System.currentTimeMillis(), consider listening to the ACTION_TIME_TICK, ACTION_TIME_CHANGED and ACTION_TIMEZONE_CHANGED Intent broadcasts to find out when the time changes.
uptimeMillis() is counted in milliseconds since the system was booted. This clock stops when the system enters deep sleep (CPU off, display dark, device waiting for external input), but is not affected by clock scaling, idle, or other power saving mechanisms. This is the basis for most interval timing such as Thread.sleep(millls), Object.wait(millis), and System.nanoTime(). This clock is guaranteed to be monotonic, and is suitable for interval timing when the interval does not span device sleep. Most methods that accept a timestamp value currently expect the uptimeMillis() clock.
elapsedRealtime() and elapsedRealtimeNanos() return the time since the system was booted, and include deep sleep. This clock is guaranteed to be monotonic, and continues to tick even when the CPU is in power saving modes, so is the recommend basis for general purpose interval timing.
Try using System.nanoTime() instead of System.currentTimeMillis().
The documentation of System.currentTimeMillis() seems to indicate that it shouldn't be used for calculating time elapsed!
you can create broadcastreceiver on action 'android.intent.action.TIME_SET'. You can know when time on your device change (by another applications).
Related
I'm developing an app that need to know the moment when the system startup, periodically.
I use System.currentTimeMillis(); to get the current "date" in millis.
I get the system elapsed real tine with SystemClock.elapsedRealTime().
I subtract the total time with the elapsed time, and I retrieve the system bootup time.
I would understand if the value change of milliseconds over time(different times in executing instructions). But for me it changes of seconds!!! Is very strange.
Someone have an idea of why?
Differences of seconds (or even tens of seconds) should not be surprising. "Current Time" corresponds to what the user perceives from the clock displayed. If you watch the displayed clock, it will not always change immediately. Read the docs:
http://developer.android.com/reference/android/os/SystemClock.html
It's pretty clear that you can't depend on currentTimeMillis for much of anything where you need millisecond accuracy. However, in most applications you really don't need that level of accuracy...
If you are trying to determine "exact boot time" from a specific moment in time later, a few seconds probably is the best you will do. Besides, what qualifies as "booted"?? When the kernel is loaded? When the user can interact with the device? When the device screen lights up? When the device can actually be unlocked?
You should probably just listen for RECEIVE_BOOT_COMPLETED (Android - Start service on boot).
Here is the Android doc: http://developer.android.com/reference/android/Manifest.permission.html#RECEIVE_BOOT_COMPLETED
This question already has answers here:
Get Real Time - Not Device Set Time in android
(3 answers)
Closed 9 years ago.
Is there a clock in devices that returns always a certain time, independent from user time settings and internet connection?
Such a time would be very helpful when checking if a license has expired.
Is there a clock in devices that returns always a certain time, independent from user time settings and internet connection?
No, sorry.
The GPS clock is independent from system clock / time settings and network connection.
You can get a timestamp by requesting a location fix and accessing Location getTime().
Of course, this is not bulletproof for license checking purposes as it can be spoofed as well. #CommonsWare's notes from comments are also worth considering:
Note that this only works on devices that have GPS, where GPS is enabled by the user, where you can get a GPS signal, and for apps where you do not mind asking for the ACCESS_FINE_LOCATION permission. Hence, this is not really "always", though it may suffice for many needs.
There is no time for this usecase.
Here is a list of the available types of time in Android:
Three different clocks are available, and they should not be confused:
System.currentTimeMillis() is the standard "wall" clock (time and
date) expressing milliseconds since the epoch. The wall clock can be
set by the user or the phone network (see setCurrentTimeMillis(long)),
so the time may jump backwards or forwards unpredictably. This clock
should only be used when correspondence with real-world dates and
times is important, such as in a calendar or alarm clock application.
Interval or elapsed time measurements should use a different clock. If
you are using System.currentTimeMillis(), consider listening to the
ACTION_TIME_TICK, ACTION_TIME_CHANGED and ACTION_TIMEZONE_CHANGED
Intent broadcasts to find out when the time changes.
uptimeMillis() is
counted in milliseconds since the system was booted. This clock stops
when the system enters deep sleep (CPU off, display dark, device
waiting for external input), but is not affected by clock scaling,
idle, or other power saving mechanisms. This is the basis for most
interval timing such as Thread.sleep(millls), Object.wait(millis), and
System.nanoTime(). This clock is guaranteed to be monotonic, and is
suitable for interval timing when the interval does not span device
sleep. Most methods that accept a timestamp value currently expect the
uptimeMillis() clock.
elapsedRealtime() and elapsedRealtimeNanos()
return the time since the system was booted, and include deep sleep.
This clock is guaranteed to be monotonic, and continues to tick even
when the CPU is in power saving modes, so is the recommend basis for
general purpose interval timing.
I want to understand the time information on the dumpsys gfxinfo log. It looks like this:
Applications Graphics Acceleration Info:
Uptime: 16264702 Realtime: 28169900
Can anyone tell me how to associate these figures with System.currentTimeMillis()?
From ActivityManagerService.java:
long uptime = SystemClock.uptimeMillis();
long realtime = SystemClock.elapsedRealtime();
pw.println("Applications Graphics Acceleration Info:");
pw.println("Uptime: " + uptime + " Realtime: " + realtime);
Also from SystemClock description:
Three different clocks are available, and they should not be confused:
System.currentTimeMillis() is the standard "wall" clock (time and
date) expressing milliseconds since the epoch. The wall clock can be
set by the user or the phone network (see setCurrentTimeMillis(long)),
so the time may jump backwards or forwards unpredictably. This clock
should only be used when correspondence with real-world dates and
times is important, such as in a calendar or alarm clock application.
Interval or elapsed time measurements should use a different clock. If
you are using System.currentTimeMillis(), consider listening to the
ACTION_TIME_TICK, ACTION_TIME_CHANGED and ACTION_TIMEZONE_CHANGED
Intent broadcasts to find out when the time changes.
uptimeMillis() is counted in milliseconds since the system was booted. This clock stops when the system enters deep sleep (CPU off, display dark, device waiting for external input), but is not affected by clock scaling, idle, or other power saving mechanisms. This is the basis for most interval timing such as Thread.sleep(millls), Object.wait(millis), and System.nanoTime(). This clock is guaranteed to be monotonic, and is suitable for interval timing when the interval does not span device sleep. Most methods that accept a timestamp value currently expect the uptimeMillis() clock.
elapsedRealtime() and elapsedRealtimeNanos() return the time since the system was booted, and include deep sleep. This clock is guaranteed to be monotonic, and continues to tick even when the CPU is in power saving modes, so is the recommend basis for general purpose interval timing.
When testing our game, that is heavily dependent on System.currentTimeMillis(), we are experiencing an annoying bug.
Our game uses an array of delta timestamps that indicates when certain things should happen. These timestamps matches a piece of music that is being played.
Testing at home gives us no problems at all. It's impossible to reproduce the bug while testing from our home.
But testing while driving around in the car, between cities, gives us sync problems between the timestamps and the music. My best guess is that Android freeze up the system, including the system timer because it's switching network, or looking for a signal?
I've tried inserting a fake hick-up in the game, by making the thread sleep a few seconds when I press a certain button. This freezes the screen (obviously), but everything is still syncing fine when the sleep is over.
The only way to reproduce this bug, is to take a trip by car or bus or train - which of course is most probably where most people will be when playing our game.
The question is of course,
what to do about it?
Does anyone have any ideas?
Read SystemClock.
System.currentTimeMillis() is the standard "wall" clock (time and
date) expressing milliseconds since the epoch. The wall clock can be
set by the user or the phone network (see setCurrentTimeMillis(long)),
so the time may jump backwards or forwards unpredictably.
uptimeMillis() is counted in milliseconds since the system was booted.
This clock stops when the system enters deep sleep (CPU off, display
dark, device waiting for external input), but is not affected by clock
scaling, idle, or other power saving mechanisms. This is the basis for
most interval timing such as Thread.sleep(millls),
Object.wait(millis), and System.nanoTime(). This clock is guaranteed
to be monotonic, and is suitable for interval timing when the interval
does not span device sleep.
I think it's better to use System.nanoTime().
According to the API docs, as well as previous SO threads, SystemClock.elapsedRealtime() is supposed to keep accurate time even when the device is sleeping. This is not what I observe.
I have written a simple clock which sits in a while (true) loop and updates the time on screen based on the value of SystemClock.elapsedRealtime(). If I synchronize the clocks on two devices, e.g. via NTP, and then proceed to toggle the screen on and off a few times on one of the devices, the displayed time will drift by up to +/- 0.7 seconds. (This only happens when the phone isn't connected to external power, so sleep mode is the likely culprit here).
Is this normal? Is this a bug in Android? Is there any way to keep ~20 millisecond timing accuracy through the sleep/wake cycles?
I have an application that communicates with a server once every minute. It synchronizes the device clock and server clock by recording the server time and SystemClock.elapsedRealtime() on startup and then calculating the server time using elapsedRealtime (I do this because the devices themselves sync time from the network and that #### can not be trusted at all).
During a one week period, running on a Galaxy Tab 2, the SystemClock.elapsedRealtime() fell behind the server clock just a few minutes under two hours. My logs reveal that the drifting pace isn't constant, so how the device is used does affect it.
While the API requires the clock to provide monotonous time, it does not guarantee accuracy. So it is not a useful method for recording time accurately over a long duration.
I have been having the same issue, so tonight I tried changing my timing method from SystemClock.elapsedRealtime() to System.currentTimeMillis(). So far so good. The time is not drifting when I click off the app and back.
I have tested it with the Runnable in a service. I am currently testing it with the Runnable in the main activity and using sharedprefs to store everything when the app loses focus.
I haven't decided which of these 2 methods is best yet - but the currentTimeMillis seems to not suffer from the drifting time issue elapsedRealtime does.
I know google doesn't recommend using currentTimeMillis for timing purposes, but it seems like it works better for keep correct time when the app loses focus.