2010-04-24 183 views
0

我正在爲Android OS編寫一個應用程序,我需要在SQLite數據庫中存儲一些時間值。我一直在使用android.text.format.Time將時間值存儲在應用程序中,然後將值作爲millis插入數據庫中作爲REAL值。在SDK模擬器上,一切正常。在唯一的手機上,我有機會測試我的應用程序(到目前爲止),我的時間代碼無法按預期工作。一些相關代碼:插入android.text.format.Time.toMillis值到droid上的SQLite數據庫的問題

private static final String DATABASE_CREATE = 
    "create table " + DATABASE_TABLE + " (" 
    + KEY_ROWID + " integer primary key autoincrement, " 
    + KEY_START + " REAL, " 
    + KEY_STOP + " REAL, " 
    + KEY_DUR + " REAL);"; 

...

private SQLiteDatabase mDb; 
ContentValues timerValues = new ContentValues(); 

...

timerValues.put(KEY_START, stime.toMillis(false)); 
timerValues.put(KEY_STOP, etime.toMillis(false)); 
timerValues.put(KEY_DURATION, stime.toMillis(false)-etime.toMillis(false)); 
int result = mDb.insert(DATABASE_TABLE, null, timerValues); 

我拉從兩個單獨的函數這一數據與代碼稍有不同的位,無論使用時間。設置(長毫米),兩者都給出不正確的結果:開始和停止值恢復正確,但持續時間超過17小時。我是否錯過了計算持續時間的事情,或者這看起來像是關於這個特定機器人的「特殊」東西?我將在週一測試另一個機器人,但任何想法都會受到讚賞。

+0

你是說在一個地方說'KEY_DUR'而在另一個地方說'KEY_DURATION'? – 2010-04-24 04:39:01

回答

0

這個問題實際上是由手機上的時區設置引起的。看來Time.toMillis會將時間輸出爲UTC時代以毫秒爲單位。當使用Time.set(long millis)設置時間時,時間假定毫秒來自Epoch,UTC的毫秒數。然後,當您請求Time.format(「%T」)時,Time會返回調整爲本地TZ的HH:MM:SS字符串。這是有道理的,除非你使用時間來衡量一個持續時間,在這種情況下可能需要一些努力來解釋TZ調整。所以,我期望的時間是20分鐘,這個時間在時代(MST或GMT-7)前一天的17:20:00被表示爲時間。好的小無證行爲。

在我的應用程序中,我選擇編寫一個簡單的實用程序類來處理將毫秒轉換爲適當的字符串。希望這篇文章能夠幫助別人解決一些頭痛問題,因爲我的google-fu沒有透露任何相關信息。

+0

沒有真正的無證件,但肯定是出乎意料的。 – schusselig 2010-04-27 20:36:12

1

除了Currie先生關於列名的說明之外,還有一個問題就是爲什麼您首先浪費存儲KEY_DURATION的空間。它可以從KEY_STARTKEY_STOP計算:

SELECT start, stop, dur=stop-start FROM whatever 

此外,android.text.format.Time只有精確到秒,所以如果你需要毫秒,你不應該使用這個類。

如果沒有這些幫助或被認爲合適,請嘗試記錄您在KEY_DURATION中輸入的值,以確定問題出在您的計算中還是存儲方式中。

+0

對不起,是的,我的意思是在兩個地方KEY_DURATION。它實際上只是我的代碼中的KEY_DUR,但我的意思是要明確地清楚片段。至於浪費空間,在我看來,在錄製時間刻錄空間並在彙總時節省一些計算是有意義的。我會嘗試在SQL中執行calc(由於某種原因,我沒有想到這一點),但我仍然對代碼爲什麼在模擬器中工作但是不在真正的droid上感到困惑。 – schusselig 2010-04-24 17:06:09

+0

計算應該很快(這只是一個減法),所以我會在節省空間方面犯錯,除非您看到具體的性能問題。我也不明白爲什麼這不適合你的硬件,因爲SQLite不應該改變AFAIK。 – CommonsWare 2010-04-24 17:19:37