我正在尝试从数据库中提取表并在另一种类型的数据库中重新加载它。问题是,在我的本地设置中,日期为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
答案 0 :(得分:3)
将Calendar
配置为使用其他Locale
。
Calendar
s将编码时间转换为当地时间。那些20多秒在Locale
中不存在不同的显示格式,所以如果你坚持保留Locale
,并且你坚持用秒设置显示日期,那么你需要采取1937年与荷兰政府合作;但是,如果将显示格式更改为其他Locale
的格式,您将发现基础时间数据结构的实际值未更改,它将在具有不同秒值的区域设置中解析为不同的时间显示。
唯一需要注意的是,如果您操纵读取和存储它之间的时间,那么您可能会无意中创建一个新的Time
或Calendar
对象,该对象将设置或重置其基础数据结构将Locale
格式化时间转换为基础数据表示。
这就是为什么最好在UTC中处理批量日期和时间处理,而不会节省夏令时。即使时间与当地时间不匹配(并且对于不同时区的人来说难以阅读),UTC的每一秒都存在,因此可以通过简单的受影响格式快速验证简单的+5秒更改时间。
此类处理的唯一警告是,您必须始终将UTC时间转换回本地时间以进行显示。根据受众的教育程度,一些荷兰人可能会惊讶地发现他们的政府不允许这样的时间存在,并且可能要求他们出现,尽管这些秒钟不是荷兰日历的一部分。 / p>
等到1582年你发现失踪的日子。
答案 1 :(得分:1)
在Java中,日期以与时区无关的方式存储在内部。 (它存储为自之后的毫秒数 - 我忘记了开始日期,是GMT 1970年1月1日?)当您输出日期时,那么它必须考虑时区。但任何内部操纵都无关紧要。你没有说你正在使用什么数据库引擎所以我不知道它如何存储日期。这些天我主要使用Postgres,它将所有日期存储在GMT中,并在输入和输出时间转换为适当的时区。
因此,如果您只是将时区设置为GMT,那么移动时区边界,夏令时等的任何更改都应该是无关紧要的。
答案 2 :(得分:0)
最简单的可能是对这些特定时间进行简单检查并相应地更改日期。
答案 3 :(得分:0)
尝试以GMT或UTC提取日期,然后以这种方式加载它们。然后,您将使用新系统的详细信息作为区域设置,而不是原始系统。