我将测量结果存储在MySQL数据库中。 度量标准包含一个时间戳字段,该字段按以下格式存储时间戳:
2015-10-10 10:10:10.11 (所以两位数毫秒)
在我的Java代码中,我使用以下命令检索此值:
了ResultSet.getTimestamp(ID)
当我打印此值时,它会给我:
2015-10-10 11:11:11.000000011
所以我试图弄清楚为什么它的行为如此,我该如何解决这个问题,以便我得到正确的价值?
编辑:
使用 select * from measurement
时,数值在数据库内正确显示我猜它应该是Java / JDBC检索它的方式。 getTimestamp和getString都给我相同的结果。
编辑2:
resultSet = statement.executeQuery("select * from measurement");
Measurement m;
while(resultSet.next()) {
m = new Measurement(
resultSet.getString(1),
resultSet.getString(2),
resultSet.getDouble(4),
resultSet.getTimestamp(3));
System.out.println(m);
}
答案 0 :(得分:1)
我从来不喜欢MySQL的JDBC驱动程序如何处理TIMESTAMP类型。我使用:
select ROUND(UNIX_TIMESTAMP(col1)*1000) FROM measurement
然后用
阅读java.util.Date d = new java.util.Date(resultSet.getLong(1));
答案 1 :(得分:0)
我一直在研究实施。即使它有点过头,我发现了一些“有趣”的信息。
com.mysql.jdbc.ResultSet.getTimestamp()
的实施有一些线索:
int year = 0;
int month = 0;
int day = 0;
int hour = 0;
int minutes = 0;
int seconds = 0;
int nanos = 0; <<< CLUE
和
if (numDigits < 9) {
int factor = (int) (Math.pow(10, 9 - numDigits));
nanos = nanos * factor;
}
和
TimeUtil.fastTimestampCreate(tz, year, month, day, hour, minutes, seconds, nanos);
因此它似乎解析了'。'之后的所有内容。以纳秒结束前导零。因此.11
变为.000000011.
所以我认为这解释了它为什么会发生......
如何解决这个问题可能有很多方面,有些是:
UNIX_TIMESTAMP
作为user5449350的回答。 UNIX_TIMESTAMPS
而不是TIMESTAMP
/ DATETIME
更正有缺陷的Date对象并使用Calendar
Date t = resultSet.getTimestamp(3);
Calendar c = Calendar.getInstance();
c.setTime(t);
c.set(Calendar.MILLISECOND, ((Timestamp)t).getNanos());
t = c.getTime();