Clojure clj-time.concure java.sql.Date.toString递减日期？

test_ns.clj

（ns测试ns
（：require[clj-time.jdbc:as-tj]
[clj-time.concure:as-tc]））
（.toString（tc/到sql日期（tc/从字符串“2018-09-28”））

=>“2018-09-27”

为什么.toString会减少日期

• 期望格式化的日期字符串与其输入匹配
• tc/to sql日期转换为java.sql.date类
• .toString方法似乎由hugsql默认jbdc适配器使用，它是用于sql事务的项目依赖项

project.clj：

（defproject我的项目“0.1.0-SNAPSHOT”
...
：min lein版本“2.0.0”
：依赖项[[org.clojure/clojure“1.10.0-beta1”]
[管道/核心“0.7.0-8”]
[风管/模块.sql“0.5.0-alpha1”]
[管道/模块记录“0.4.0-alpha1”]
[duct/database.sql.hikaricp“0.3.3”]
[com.walmartlabs/lacinia“0.21.0”]
[com.rpl/specter“1.1.1”]
[net.mikera/core.matrix“0.62.0”]
[com.wsscode/pathm“2.2.4”]
[org.clojure/core.async“0.4.474”]
[org.postgresql/postgresql“42.2.5”]
[org.clojure/core.async“0.4.490”]
[com.layerware/hugsql“0.4.9”]
[柴郡“5.8.1”]
[骆驼蛇串“0.4.0”]
[山核桃“0.7.1”]
[白炽灯“1.9.3”]
[clj http“3.9.1”]
[环境“1.1.0”]]
：插件[[lein environ“1.1.0”]
[风管/莱因风管“0.11.0-6”]
[lein exec“0.3.7”]]
：main^：跳过aot portfolio-management.main
：测试路径[“测试”]
：源路径[“src”]
：目标路径“target/%s”
：资源路径[“资源”“目标/资源”]
：准备任务[“javac”“compile”[“run”“：风管/编译器”]]
：简介
{:dev[:project/dev:profiles/dev]
：repl{:prep tasks^:replace[“javac”“compile”]
：repl选项{：init ns user}
：uberjar{:aot:all}
：profiles/dev{}
：project/dev{：源路径[“dev/src”]
：资源路径[“开发人员/资源”]
：依赖项[[integrant/repl“0.3.1”]
[eftest“0.4.1”]
[kerodon“0.9.0”]
]}})

编辑

~$java-版本
openjdk版本“1.8.0_191”
OpenJDK运行时环境（构建1.8.0_191-8u191-b12-2ubuntu0.18.04.1-b12）
OpenJDK 64位服务器虚拟机（构建25.191-b12，混合模式）

我很确定这是一个时区问题，正如Carcigenicate已经指出的那样。

from string

解析UTC时区中的字符串，java.sql.Date使用默认的JVM时区。 如果您所在的时区“落后于”UTC（向西），则返回的结果是正确的，因为在这些时区中，日期2018-09-28 00:00:00实际上是2017-09-27

(java.util.TimeZone/setDefault(java.util.TimeZone/getTimeZone "GMT"))
(.toString (tc/to-sql-date (tc/from-string "2018-09-28")))
;; => "2018-09-28"

(java.util.TimeZone/setDefault(java.util.TimeZone/getTimeZone "GMT-1"))
(.toString (tc/to-sql-date (tc/from-string "2018-09-28")))
;; => "2018-09-27"

---

您不应该使用java.sql.Date并期望它返回UTC时区中的日期，只要该时区不是您的默认时区。

。带有

project.clj

且代码返回“2018-09-28”的空项目可以复制。我不得不删除

clj time.jdbc

：require

，因为它导致了错误，但代码仍然运行，因此给出了

“2018-09-27”

。您对

clj time.jdbc

的要求是否导致了

没有这样的变量：jdbc/IResultSetReadColumn

错误？有趣的是，

（让[d（tc/to-sql-date（tc/from-string“2018-09-28”）[（.getMonth d）（.getDate d）]

返回

[8 27]

。似乎有些东西把月份和天数看作从0开始，而它们应该从1开始。我认为这是一个时区问题。其中一个日期构造函数考虑了本地时间，而另一个没有。注意。这将是一个问题，因为

到sql时间

通过处理从纪元开始的毫秒来进行转换。这也可能解释为什么埃尔文不能重新编程，因为这取决于当地时间。我想这是图书馆的错误。谢谢！将默认时区设置为GMT解决了报告的行为。没想到date对象会有这样的依赖关系，但这是有道理的。是的，这有点棘手，我们在生产中也受到了影响。因为我们在GMT+1时区，但我们的一些客户使用GMT-X运行，这相当棘手；尤其是在将数据保存到数据库时，转换是“静默”完成的。