我说的是这个接口方法：
最常用的实现是 cachedrowset 中的实现：
你会注意到这个实现做了两件非常奇怪的事情：
1）它修改作为参数传递的日历，即使还有一个返回值
2) 它从 SQL 中提取所有时间信息，除了毫秒，它来自作为参数传递的日历。
接口描述相当不清楚，但假设实现是正确的 - 这种方法有什么意义？我可以理解一种方法，它需要一个日历来提取时区，而不需要修改它。但是拿一个日历，修改它，不仅提取区域，还提取毫秒......
有没有人对此 API 背后的历史/设计/推理有任何见解？
2 回答
2
这似乎是对 JDBC API 文档的错误解释（不幸的是javax.sql.rowset，这些错误解释更多）。
默认情况下，JDBC 驱动程序需要存储或检索时间或时间戳，就好像存储在数据库中的时间在 JVM 的当前时区中一样。由于这并不总是您想要的，API 提供了提供Calendar对象的方法，您需要使用该对象来派生要使用的实际时区（我不知道他们为什么不使用java.util.TimeZone）。
这在PreparedStatement.setTimeStamp中指定：
使用对象，驱动程序可以在考虑自定义时区
Calendar的情况下计算时间戳。如果未指定对象，则驱动程序使用默认时区，即运行应用程序的虚拟机的时区。Calendar
getTimestamp中的方法ResultSet遵循（或应该遵循）这些相同的规则。
因此，如果数据库存储时间“11:20”并且您的本地时区是 CET (UTC+1)，则检索到的时间是 10:20 UTC (11:20 CET)。但是，如果我Calendar在 GMT 中提供，返回的时间应该是 11:20 UTC（12:20 CET）。
于 2015-01-07T11:00:28.903 回答
1
SQL 数据库以年、月、日、小时、分钟、秒等形式存储时间戳的日期和时间值。这些值指定的时间实例取决于解释它们的时区（例如 2014 年 1 月 1 日 15 日） :00:00 在欧洲与美国不同）。时区可能是也可能不是时间戳的一部分，具体取决于列的类型。
Javajava.sql.Timestamp和java.util.Date类代表一个时间实例，与时区无关（或者更确切地说，在固定的 UTC 时区中）。
如果 SQL 数据库中的列不存储时区信息以及日期+时间，则为了从此类时间戳创建 JavaDate或TimeStamp对象需要时区，以便它可以及时指向特定实例（在参考 UTC时区）。
所讨论的ResultSet.getTimestamp()方法可用于获取 SQL 时间戳数据并Timestamp使用参数Calendar对象中设置的时区信息将其转换为 Java 实例。
于 2015-01-07T10:40:59.340 回答