异常Java SQL时间戳日历检索行为 - 从日历需要毫秒? [英] Bizarre Java SQL Timestamp Calendar retrieval behaviour - takes milliseconds from Calendar?

查看:159
本文介绍了异常Java SQL时间戳日历检索行为 - 从日历需要毫秒?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

此代码段:

private Date fetchTimestampFromDatabase(SqlRowSet rs, String field) {

try {

  System.out.println(rs.getTimestamp(field));
  for (int i = 0; i < 10; i++) {
    System.out.println(rs.getTimestamp(field, Calendar.getInstance(TimeZone.getTimeZone("UTC"))));
    Thread.sleep(200);
    ...

得到以下结果:

2014-06-06 10:44:58.696
2014-06-06 12:44:58.75
2014-06-06 12:44:58.95
2014-06-06 12:44:58.15
2014-06-06 12:44:58.35
2014-06-06 12:44:58.55
2014-06-06 12:44:58.75
2014-06-06 12:44:58.95
2014-06-06 12:44:58.15
2014-06-06 12:44:58.35
2014-06-06 12:44:58.55

正确应用,但是为什么在地球上的毫秒被推测,可能是从日历实例?

Great, the timezone offset is correctly applied, but why on earth are the milliseconds being jiggled, presumably taken from the calendar instance?

读取方法的javadoc,我发现一个相当含糊的语句,似乎这意味着这是指定的行为:

Reading the javadoc of the method, I found a rather ambiguous statement that seems to imply this is behaving as specified:


此方法使用给定的日历为时间戳构造一个适当的毫秒值

"This method uses the given calendar to construct an appropriate millisecond value for the timestamp"

源文件确认:

cal.set(Calendar.YEAR, defaultCal.get(Calendar.YEAR));
cal.set(Calendar.MONTH, defaultCal.get(Calendar.MONTH));
cal.set(Calendar.DAY_OF_MONTH, defaultCal.get(Calendar.DAY_OF_MONTH));
cal.set(Calendar.HOUR_OF_DAY, defaultCal.get(Calendar.HOUR_OF_DAY));
cal.set(Calendar.MINUTE, defaultCal.get(Calendar.MINUTE));
cal.set(Calendar.SECOND, defaultCal.get(Calendar.SECOND));
return new java.sql.Timestamp(cal.getTime().getTime());

有人知道为什么没有设置Calendar.MILLISECOND?

Does anyone know why the Calendar.MILLISECOND aren't being set?

干杯

推荐答案

文档似乎表明,日历。
然而,它有点不同于文档(从其中扩展RowSet)。

The documentation does seem to indicate that the millisecond value is expected to be provided in the Calendar. However, it is somewhat different than the documentation of ResultSet (from which RowSet extends).


如果底层数据库
不存储时区信息,则此方法使用给定的日历为时间戳构造适当的
毫秒值。

This method uses the given calendar to construct an appropriate millisecond value for the timestamp if the underlying database does not store timezone information.

这似乎将2个看似无关的概念绑在一起 - 数据库中存在时区信息和数据库中时间戳字段的精度。

This seems to tie 2 seemingly unrelated concepts together - presence of timezone information in the database and precision of the timestamp field in the database.

源代码中的问题实际上在日历填充之前开始:

The problem in the source code actually starts just before the calendar population:

   defaultCal.setTime((java.util.Date)value);

通过将Timestamp转换为java.util.Date,所有部分第二个数据都会丢失。如时间戳 javadoc:

By casting the Timestamp to a java.util.Date, all the partial second data was lost. As described in the Timestamp javadoc:


注意:此类型是一个java.util.Date和一个单独的
nanoseconds值的复合。只有整数秒存储在
java.util.Date组件中。

Note: This type is a composite of a java.util.Date and a separate nanoseconds value. Only integral seconds are stored in the java.util.Date component.

这篇关于异常Java SQL时间戳日历检索行为 - 从日历需要毫秒?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆