问题
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
回答1:
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.
回答2:
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!
回答3:
you can create broadcastreceiver on action 'android.intent.action.TIME_SET'. You can know when time on your device change (by another applications).
来源：https://stackoverflow.com/questions/22377219/does-time-jump-in-android-devices