java Date to String - 有时CET有时CEST答案

【问题标题】：java Date to String - sometimes CET sometimes CESTjava Date to String - 有时CET有时CEST
【发布时间】：2013-10-30 23:12:39
【问题描述】：

奇怪的东西。我有 SQLite Android 数据库，日期保持为长值。我将它们读作 Date 对象，例如：

new Date (cursor.getLong(4))

接下来在显示时，我使用 toString() 方法将 Date 对象转换为 String。但是有时显示的字符串包含 CET，有时包含 CEST。

当然，添加时区信息这一事实并不奇怪。令人惊讶的是，在同一设备上，值同时从数据库中获取，是长值，因此不包含任何区域时间信息，java 有时会添加 CET，有时会添加 CEST。为什么会有这样的差异？

唯一的区别是给出结果 CEST 的 long 值的时间等于 00:00:00，而给出结果 CET 的 long 值的时间不同。

有什么想法吗？

【问题讨论】：

我认为这取决于特定日期所在的一年中的时间。请提及导致不同时区的两个日期。
我正在同时进行转换 - 在第二次转换之后进行一次转换。并且 AFAIU 日期只要保留没有任何区域信息，如果在将日期转换为长时考虑从 java 程序区域存储（GMT 时间保留为长值），如果来自其他程序，它取决于它是如何工作的。
A Date 对象表示从称为“纪元”的瞬间开始的毫秒数。即使将Date 对象转换为long，也不会使用区域信息。
好的，为什么在将 long 转换为 Date 并在 String 旁边时，我得到两个不同的时区？
看看这个答案 - stackoverflow.com/questions/2092340/…

【解决方案1】：

这些值本身完全与时区无关，但您的设备不是。您的设备有两个时区，CET 和 CEST，作为其区域设置的一部分。夏令时生效/现在/将要生效期间的日期以 CEST 给出，其他日期报告为 CET。

如果您将设备设置为不遵守夏令时的区域设置，则只会报告该时区。

要了解为什么这样做有意义，请考虑您是否问我现在几点了，我说“13:35 CEST”。由于 CEST 是 UTC+2，我是对的，但您可能会感到困惑。因为 CEST 在一年中的这个时候不使用，所以在 CET 中给出时间才有意义。这就是时区因日期而异的原因。

【讨论】：

现在这很清楚，尽管乍一看很令人惊讶。我只是想知道一件事。如果我的代码中有 (new Date()).getTime() （以毫秒为单位给出当前日期，假设它是 2013.10.31 00:45），接下来我将此信息存储在数据库中，而其他人则在不同的时间zone 将采用这个 long 值，转换为 Date 对象并在 String 旁边。他/她会得到相同的字符串 2013.10.31 00:45 CET 还是系统会考虑不同的时区并显示 ex. 2013.10.31 02:45 Zone+2（不管是什么）？或者也许是 2013.10.31 00:45 Zone+2？
如果转换为毫秒的日期对象总是给出从“纪元”到当前格林尼治标准时间或本地时间的毫秒数？
@user2707175 不同语言环境中的其他人在创建新的日期时会得到不同的字符串。
@user2707175 无论时区如何，自纪元以来的秒数都是相同的。想象一下，如果时代是“当你提交我正在回复的评论时”。无论某人在哪个时区，他们仍然会看到提交时间为“3 分钟前”（如果他们现在看的话）。
@blahdiblah 感谢您的回答，但我还不清楚 - 根据 GMT 区域或本地区域，Date 是否始终保持毫秒数？