時間跳躍在Android設備上？

System.currentTimeMillis（）給錯誤的時間。它從1980年返回時間值通過此功能拍攝的時間值有時也與實際時間不同。由功能時間跳躍在Android設備上？

315977198121 
315965244789 
316002166580 
315982533137

2014-03-13 DroidBoy

如果設備有SIM卡，它將（或應該）自動更新使用電話信號的時間。在沒有SIM卡的設備（例如平板電腦）中，我看到了一些令人難以置信的時鐘漂移，但沒有像這樣。這個代碼運行在哪種設備上？或者它是一個模擬器？ – CurlyPaul

@CurlyPaul此代碼在Android設備上運行，尤其是華爲設備，不知道這裏出了什麼問題 – DroidBoy

另外我注意到1980年1月6日的值很多 – DroidBoy

是，通過System.currentTimeMillis的（返回）時間可跳躍，例如由於設備時鐘可能已經漂移，並且通過其他觀察到由於來自網絡

時間獲取準確的時間被複位例如，由於時區更改或夏令時，API可能還會跳得更多。

（但是這並不能解釋爲什麼你在那1980坦率地說聽起來像一個設備故障突然看見倍）所使用的值來獲得一個持續時間

幽州。這是一個錯誤 - 您應該使用SystemClock.elapsedRealtime（）進行持續時間計算。

查看該文檔在SystemClock，具體注意：

Three different clocks are available, and they should not be confused:

System.currentTimeMillis的（）是標準的「壁」時鐘（時間和日期）表達，因爲曆元毫秒。掛鐘可以由用戶或電話網絡設置（請參閱setCurrentTimeMillis（long）），因此時間可能會跳轉或不可預測地轉發。只有在與真實世界日期和時間的對應很重要時才能使用此時鐘，例如在日曆或鬧鐘應用程序中。間隔或經過時間測量應使用不同的時鐘。如果您使用的是System.currentTimeMillis（），請考慮監聽ACTION_TIME_TICK，ACTION_TIME_CHANGED和ACTION_TIMEZONE_CHANGED Intent廣播以瞭解時間更改的時間。
uptimeMillis（）以系統啓動後的毫秒計算。當系統進入深度睡眠（CPU關閉，顯示黑暗，設備等待外部輸入）時，此時鐘停止，但不受時鐘縮放，空閒或其他節能機制的影響。這是大多數間隔計時的基礎，例如Thread.sleep（millls），Object.wait（millis）和System.nanoTime（）。這個時鐘保證是單調的，並且當間隔不跨越設備睡眠時適用於間隔定時。接受時間戳值的大多數方法當前都需要uptimeMillis（）時鐘。
elapsedRealtime（）和elapsedRealtimeNanos（）返回自系統啓動以來的時間，幷包含深度睡眠。這個時鐘保證是單調的，即使在CPU處於省電模式時也會繼續保持時鐘狀態，所以是通用間隔時序的推薦基礎。

2014-03-26 15:25:20 zmarties

DST將*不*影響'currentTimeMillis'。時區完全不會影響它 - 這只是Unix時代以來的毫秒數。 –

感謝喬恩 - 編輯答案，以明確由於夏令時導致的時間跳躍通過其他API觀察到，而不是'currentTimeMillis' – zmarties

正確。您可能想要現在更改第一段的結構，因爲您的「各種原因」現在是1 :) –

返回的一些樣本值嘗試使用的System.nanoTime()代替System.currentTimeMillis()。

System.currentTimeMillis()的文檔似乎表明它不應該用於計算已過時間！

2014-03-25 23:53:32 nyx

你可以在action'android.intent.action.TIME_SET'上創建broadcastreceiver。您可以知道設備上的時間何時發生變化（由其他應用程序）。

2014-03-29 16:58:35

回答