Проблема вставки значения android.text.format.Time.toMillis в базу данных SQLite на droid - PullRequest
Новая
       18

Проблема вставки значения android.text.format.Time.toMillis в базу данных SQLite на droid

0 голосов
/ 24 апреля 2010

Я пишу приложение для ОС Android, и мне нужно сохранить некоторые значения времени в БД SQLite. Я использую android.text.format.Time для хранения значений времени в приложении, а затем вставляю значения в виде миллис в БД в качестве РЕАЛЬНЫХ значений. На эмуляторе 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 (длинный миллис), и оба дают неверные результаты: значения начала и остановки возвращаются правильно, но длительность также составляет 17 часов большой. Я что-то упускаю из расчета длительности или кажется, что в этом конкретном дроиде есть что-то особенное? У меня будет еще один дроид для тестирования в понедельник, но любые идеи приветствуются.

Ответы [ 2 ]

1 голос
/ 24 апреля 2010

Помимо примечания г-на Керри о названиях столбцов, существует вопрос о том, почему вы тратите пространство на хранение KEY_DURATION. Его можно рассчитать из KEY_START и KEY_STOP: 

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

Кроме того, android.text.format.Time имеет только вторую точность, поэтому, если вам нужны миллисекунды, вам не следует использовать этот класс.

Если ни один из них не помогает или считается подходящим, попробуйте записать значение, которое вы вводите KEY_DURATION, чтобы увидеть, связана ли проблема с вашими вычислениями или как они хранятся.

0 голосов
/ 26 апреля 2010

Фактически проблема была вызвана настройками часового пояса на телефоне. Похоже, что Time.toMillis будет экспортировать время в миллисекундах с эпохи UTC. При установке времени с использованием Time.set (long millis), Time предполагает, что миллисекунды - это миллисекунды от Epoch, UTC. Когда вы затем запрашиваете Time.format ("% T"), Time возвращает строку HH: MM: SS, настроенную на локальный TZ. Это имеет смысл, если только вы не используете Time для измерения продолжительности, и в этом случае, вероятно, следует приложить определенные усилия для учета корректировки TZ. Итак, то, что я ожидал, это истекшее время, скажем, 20 минут, которое, как оказалось, было представлено временем в 17:20:00 накануне эпохи (MST или GMT-7). Хорошее небольшое недокументированное поведение.

В моем приложении я решил написать простой служебный класс для преобразования в миллисекунды в соответствующую строку. Надеюсь, этот пост избавит кого-то еще от головной боли, так как мой google-fu не выявил ничего связанного.

...