Java 缺失 28 秒
我正在尝试从数据库中提取表并将其重新加载到另一种类型的数据库中。问题是，在我的本地设置中，1937 年 7 月 1 日的日期在 00:00:00 时会出现获取时间戳的问题。在荷兰，他们于 1937 年改变了子午线，导致 1937 年 7 月 1 日的前 28 秒不存在。
当我将日期读入日历以重新格式化输出时，时间会更改为日期之前 28 秒； 6月30日23:59:32或7月1日00:00:28（取决于司机） 有人知道解决这个问题的方法吗？
http://themagicofscience.blogspot.com/2010/08 /java-puzzler-1-july-1937.html
I'm trying to extract a table from a database and reloading it in another type of database. The problem is that with my local settings the date 1 july 1937 poses a problem of gettng the timestamp when its 00:00:00. In the netherlands they changed meridians in 1937 causing the first 28 seconds of 1st of july 1937 not existing.
When i'm reading the date into a calendar to reformat the output, the time changes to either 28 seconds before the date; june 30th 23:59:32 or july 1st 00:00:28 (depending on driver)
Anyone knows a workaround around this problem?
http://themagicofscience.blogspot.com/2010/08/java-puzzler-1-july-1937.html
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
配置您的
日历以使用不同的区域设置。日历将编码时间转换为当地时间。在该Locale中，不同的显示格式不存在这 20 多秒，因此，如果您坚持保留该Locale，并且坚持显示设置秒数的日期，那么，那么你需要在 1937 年向荷兰政府提出此事；但是，如果您将显示格式更改为不同的区域设置，您会发现底层时间数据结构的实际值没有更改，它将解析为具有不同区域设置的不同时间。显示不同的秒值。唯一需要注意的是，如果您操纵读取和存储之间的时间，那么您可能会无意中创建一个新的
Time或Calendar对象，这将设置或重置其底层基于将Locale格式的时间转换为底层数据表示的数据结构。这就是为什么最好在没有夏令时的情况下以 UTC 进行批量日期和时间处理。尽管时间与当地时间不匹配（对于不同时区的人来说更难读取），但 UTC 的每一秒都存在，因此简单的 +5 秒更改可以通过受影响的简单格式快速验证时间。
这种处理的唯一警告是，稍后您必须始终将 UTC 时间转换回本地时间以进行显示。根据观众的教育程度，一些荷兰人可能会惊讶地发现他们的政府不允许这样的秒存在，并且可能会要求显示它们，尽管规定这样的秒不属于荷兰日历的一部分。
等待您发现 1582 年失踪的日子。
Configure your
Calendarto use a differentLocale.Calendars translate the encoded time into the local time. Those 20+ seconds just don't exist with different display formats in thatLocale, so if you insist on keeping thatLocale, and you insist on displaying dates with seconds set so, then you need to take it up with the Dutch government in 1937; however, if you change the display formatting to that of a differentLocale, you will discover that the actual value of the underlying time data structure wasn't changed, it will resolve to different times in locales that have different seconds values to display.The only caveats is that should you manipulate the time between reading it and storing it, then you might inadvertently create a new
TimeorCalendarobject, which would set or reset its underlying data structures based on a translation of theLocaleformatted time into the underlying data representation.This is why it is best to handle bulk date and time handling in UTC, without daylight savings. Even though the times don't match up to the local times (and are harder to read for people in different time zones), every second of UTC exists, so simple +5 second changes can quickly be verified by a simple formatting of the impacted time.
The only caveat with this sort of handling is that later, you must always translate UTC time back to local time for display. Depending on the education of your audience, some of the Dutch might be shocked to find that their government didn't allow such seconds to exist and might demand that they are shown despite the rulings that such seconds are not part of the Dutch calendar.
Just wait until you discover the missing days back in 1582.
在 Java 中，日期以独立于时区的方式在内部存储。 （它存储为自以下时间以来的毫秒数——我忘记了开始日期，是格林尼治标准时间 1970 年 1 月 1 日吗？）当您输出日期时，它必须考虑时区。但任何内部操纵都不重要。您没有说您正在使用什么数据库引擎，所以我不知道它如何存储日期。这些天我主要使用 Postgres，它以 GMT 存储所有日期，并在输入和输出时间在适当的时区之间进行转换。
因此，如果您只是将时区设置为 GMT，那么移动时区边界、夏令时等的任何更改都应该无关紧要。
In Java, a date is stored internally in a time-zone independent way. (It's stored as the number of milliseconds since -- I forget the starting date, was it Jan 1, 1970 GMT?) When you output a date, THEN it has to take the time zone into account. But any internal manipulations shouldn't matter. You didn't say what database engine you're using so I don't know how it stores dates. I'm mostly working with Postgres these days, which stores all dates in GMT and converts to and from the appropriate time zone at input and output time.
So if you just set your time zone to GMT, then any changes for moving time zone boundaries, daylight savings time, etc should be irrelevant.
最简单的可能是对这些特定时间进行简单检查并相应地更改日期。
The simplest would probably be to do simple check for those specific times and change the date accordingly.
尝试提取 GMT 或 UTC 格式的日期，然后以这种方式加载它们。然后，您将使用新系统的区域设置详细信息，而不是原始系统。
Try and extract the dates in GMT or UTC, then load them back in that way. Then you'll use the details of the new system for the locale, rather than the original system.