建设网站实训报告,wordpress分级标题,封面型网页网站有哪些内容,精品课程网站建设步骤在jOOQ邮件列表上#xff0c;最近有一个有趣的讨论#xff0c;关于jOOQ当前缺乏对TIMESTAMP WITH TIME ZONE数据类型的现成支持。 没有人说日期#xff0c;时间和时区很容易#xff01; 这里有一个有趣的部分#xff0c;我建议阅读#xff1a; 虚假的程序员相信时间 当… 在jOOQ邮件列表上最近有一个有趣的讨论关于jOOQ当前缺乏对TIMESTAMP WITH TIME ZONE数据类型的现成支持。 没有人说日期时间和时区很容易 这里有一个有趣的部分我建议阅读 虚假的程序员相信时间 当那还不够时还请阅读 更多的虚假程序员相信时间 我个人喜欢程序员错误地认为“ Unix时间是自1970年1月1日以来的秒数”。 …Unix时间无法代表leap秒 返回JDBC 这是Jaybird开发人员Firebird JDBC驱动程序 Mark Rotteveel提出的一个有趣的Stack Overflow答案 java.sql.Timestamp时区是否特定 可以按照以下方式观察Mark的解释我在这里使用PostgreSQL Connection c getConnection();
Calendar utc Calendar.getInstance(TimeZone.getTimeZone(UTC));try (PreparedStatement ps c.prepareStatement(select ?::timestamp, ?::timestamp, ?::timestamp with time zone, ?::timestamp with time zone
)) {ps.setTimestamp(1, new Timestamp(0));ps.setTimestamp(2, new Timestamp(0), utc);ps.setTimestamp(3, new Timestamp(0));ps.setTimestamp(4, new Timestamp(0), utc);try (ResultSet rs ps.executeQuery()) {rs.next();System.out.println(rs.getTimestamp(1) / rs.getTimestamp(1).getTime());System.out.println(rs.getTimestamp(2, utc) / rs.getTimestamp(2, utc).getTime());System.out.println(rs.getTimestamp(3) / rs.getTimestamp(3).getTime());System.out.println(rs.getTimestamp(4, utc) / rs.getTimestamp(4, utc).getTime());}
} 上面的程序使用Java和DB中使用时区而不使用时区的所有排列并且输出始终相同 1970-01-01 01:00:00.0 / 0
1970-01-01 01:00:00.0 / 0
1970-01-01 01:00:00.0 / 0
1970-01-01 01:00:00.0 / 0 如您所见在每种情况下UTC时间戳0均已正确存储并从数据库中检索到。 我自己的语言环境是瑞士即CET / CEST在Epoch是UTC 1这就是在Timestamp.toString()上获取输出的地方。 当您在SQL和/或Java中使用时间戳文字时事情会变得很有趣。 如果这样替换绑定变量 Timestamp almostEpoch Timestamp.valueOf(1970-01-01 00:00:00);ps.setTimestamp(1, almostEpoch);
ps.setTimestamp(2, almostEpoch, utc);
ps.setTimestamp(3, almostEpoch);
ps.setTimestamp(4, almostEpoch, utc); 这又是我在CET / CEST上获得的东西 1970-01-01 00:00:00.0 / -3600000
1970-01-01 00:00:00.0 / -3600000
1970-01-01 00:00:00.0 / -3600000
1970-01-01 00:00:00.0 / -3600000 即不是Epoch而是我首先发送到服务器的时间戳文字。 请注意绑定/获取的四种组合仍然始终产生相同的时间戳。 让我们看看如果写入数据库的会话使用与从数据库中获取会话不同的时区假设您在PST中我再次使用CET或UTC会发生什么情况。 我正在运行此程序 Calendar utc Calendar.getInstance(TimeZone.getTimeZone(UTC));Calendar pst Calendar.getInstance(TimeZone.getTimeZone(PST));try (PreparedStatement ps c.prepareStatement(select ?::timestamp, ?::timestamp, ?::timestamp with time zone, ?::timestamp with time zone
)) {ps.setTimestamp(1, new Timestamp(0), pst);ps.setTimestamp(2, new Timestamp(0), pst);ps.setTimestamp(3, new Timestamp(0), pst);ps.setTimestamp(4, new Timestamp(0), pst);try (ResultSet rs ps.executeQuery()) {rs.next();System.out.println(rs.getTimestamp(1) / rs.getTimestamp(1).getTime());System.out.println(rs.getTimestamp(2, utc) / rs.getTimestamp(2, utc).getTime());System.out.println(rs.getTimestamp(3) / rs.getTimestamp(3).getTime());System.out.println(rs.getTimestamp(4, utc) / rs.getTimestamp(4, utc).getTime());}
} 它产生以下输出 1969-12-31 16:00:00.0 / -32400000
1969-12-31 17:00:00.0 / -28800000
1970-01-01 01:00:00.0 / 0
1970-01-01 01:00:00.0 / 0 第一个时间戳记是将Epoch存储为PST16:00然后数据库中删除了时区信息这将Epoch变成了您在Epoch处的本地时间-28800秒/ -8h即真正存储。 现在当我从自己的时区CET获取该时间时我仍然想要获取当地时间16:00。 但是在我的时区中这不再是-28800秒而是-32400秒-9h。 够古怪吗 当我获取存储的本地时间16:00时事情发生了相反的变化但是我强迫获取发生在UTC中这将产生您存储的时间戳最初是PST-28800秒。 但是在我的时区CET中打印此时间戳-28800秒时现在是17:00。 当我们在数据库中使用TIMESTAMP WITH TIME ZONE数据类型时将保持时区PST并且当我获取Timestamp值时无论使用CET还是UTC我仍然会得到Epoch它已安全地存储到了数据库在CET中打印为01:00。 ew。 TL; DR 使用jOOQ时 如果正确的UTC时间戳对您很重要请使用TIMESTAMP WITH TIMEZONE但是您必须实现自己的数据类型Binding 因为jOOQ当前不支持该数据类型。 一旦使用了自己的数据类型Binding就可以使用Java 8的time API它比java.sql.Timestamp 丑陋的Calendar更好地表示了这些不同的类型。 如果当地时间对您很重要或者您不在跨时区工作则可以使用TIMESTAMP和jOOQ的Field Timestamp。 幸运的是如果您像我一样可以在一个只有一个时区的很小的国家/地区进行操作而大多数本地软件都不会遇到此问题。 翻译自: https://www.javacodegeeks.com/2015/07/whats-even-harder-than-dates-and-timezones-dates-and-timezones-in-sql-jdbc.html
