0

私は Android OS 用のアプリを作成しています。時間の値を SQLite DB に保存する必要があります。私はandroid.text.format.Timeを使用して時間値をアプリに保存し、値をミリ秒としてDBにREAL値として挿入しています。SDK エミュレーターでは、すべてが完全に機能します。アプリをテストする機会があった唯一の電話 (これまでのところ) で、期間コードが期待どおりに機能しません。関連するコード:

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);

どちらも Time.set(long millis) を使用して、コードのビットがわずかに異なる 2 つの別個の関数からこのデータを取得します。両方とも誤った結果をもたらします。開始値と停止値は正しく返されますが、期間が 17 時間長すぎます。持続時間の計算について何かが欠けているのでしょうか、それともこの特定のドロイドに「特別な」何かがあるように見えますか? 月曜日にテストする別のドロイドがありますが、アイデアは大歓迎です。

4

2 に答える 2

1

列名に関する Currie 氏のメモに加えて、そもそもなぜ保存するスペースを無駄にしているのかという疑問がありますKEY_DURATION。KEY_STARTとから計算できますKEY_STOP。

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

また、android.text.format.Time秒の精度しかないため、ミリ秒が必要な場合は、そのクラスを使用しないでください。

これらのいずれも役に立たない、または適切と見なされない場合は、入力している値を記録してみてKEY_DURATION、問題が計算にあるのか、それとも保存方法にあるのかを確認してください。

于 2010-04-24T11:32:29.720 に答える
0

この問題は、実際には電話のタイムゾーン設定が原因であることが判明しました。Time.toMillisは、UTCのエポックからミリ秒単位で時刻をエクスポートするようです。Time.set（long millis）を使用して時間を設定する場合、Timeはミリ秒がUTCのエポックからミリ秒であると想定します。次にTime.format（ "％T"）を要求すると、TimeはローカルTZに調整されたHH：MM：SS文字列を返します。これは、期間を測定するために時間を使用している場合を除いて意味があります。その場合、TZ調整を説明するために何らかの努力を払う必要があります。したがって、たとえば20分の経過時間と予想したものは、エポックの前日の17:20:00（MSTまたはGMT-7）としてTimeで表されることがわかりました。文書化されていないちょっとした振る舞い。

私のアプリケーションでは、ミリ秒から適切な文字列への変換を処理するための単純なユーティリティクラスを作成することを選択しました。私のgoogle-fuが何も関係していないことを明らかにしたので、この投稿が他の誰かの頭痛の種を救うことを願っています。

于 2010-04-25T23:47:52.713 に答える