2010-04-24 149 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