将Joda LocalTime转换为java.sql.Date
将Joda LocalTime转换为java.sql.Date
要进行JDBC查询,我需要传递日期。日期存储在PostgreSql数据库的Date
字段类型中,它表示特定的日期而没有时间。
由于我只需要日期,所以决定使用只代表日期的具体对象,即来自Joda-Time包的LocalDate
。我认为这很重要,因为如果我使用DateTime对象,它还将携带冗余的时间数据,同时它可能会在夏令时结束时导致错误,当时时钟向后调整一小时(尽管这种情况极为罕见,但并非不可能)。
但是当我开始尝试用preparedStatement.setDate
方法的可接受参数来设置LocalDate
对象时,我没有找到合适的方法。
setDate
接受java.sql.Date
作为参数。构造java.sql.Date
对象的唯一选项是传递它的毫秒时间。
但是这破坏了使用Joda-Time包中的LocalDate
的所有目的,因为在这种转换中,我们回到了毫秒级别,并且在这些转换发生时,时钟可能向后调整一小时并将日期更改为前一天。
因此,现在我在我的代码中有这一行:
preparedStatement.setDate(1, new java.sql.Date(localDate.toDate().getTime()));
但这是将LocalDate
转换为setDate
可接受的格式的最佳方法吗?
我的关注点是否与夏令时及其相应的时钟偏移有关?
有没有更好的方法将日期(仅日期而不是时间)传递给JDBC preparedStatement?
你的技术使用起来应该是安全的,因为 LocalDate#toDate
会考虑所有的时区问题。结果的毫秒数与上下文无关:它唯一地与在转换过程中使用的区域设置中在那个时间点上有效的时区相关联。换句话说,即使时区规定在此期间发生变化,如果你在一年中重复转换完全相同的毫秒值,你将始终得到完全相同的答案,因为JDK引用了全球所有时区更改的完整历史记录的数据库。
在考虑这些问题时,重要的是要记住,你当前的时区对转换没有影响,转换是由你的区域设置参数化的,并且仅在转换的瞬间的上下文中解决时区。
我完全理解你对所有这些的不安:它将一个简单和直接的操作变成了一个复杂的计算迷宫,这只会带来麻烦。希望随着 Java 8 和基于 JodaTime 的新(是的,又一个!)日期/时间 API 的到来,情况会好转。