Java Date toString包含时区…为什么?

CDT是否只是因为本地机器时区是CDT?

用于显示的时区基于默认时区。

日期中的毫秒是相对于历元的,它没有自己的时区。

拍摄时间为格林尼治标准时间1970年1月1日00:00,或者如果您喜欢1969年12月31日17:00 CDT拍摄。

将隐含地在本地机器时区中

本地时区的使用仅用于显示目的。使用其他时区或序列化 Date 并将其发送到另一时区的机器,它将再次使用本地时区。

你是对的,它显示CDT在 toString() 因为你的 locale 表示您所在的时区正确。这个 Date 对象本身不关心时区,它是一个以毫秒为单位的Unix时代的包装器。通常,您应该使用 到字符串() 用于调试目的,并使用 a date formatter 以实际向用户显示日期(可选地指定一个明确的时区,而不是由用户的语言环境指定的时区)。

这个 Javadoc 对于 Date.toString() 它只指定字符串的格式,实际上没有说明使用哪个时区。我不会依赖 到字符串() 始终返回默认值 Locale 在Java的每个实现中。

通过使用正确的格式,可以使用日期的自定义表示

阅读这篇文章,可能会对你有所帮助 Change date format in a Java string

大纪元开始后的毫秒数不在UTC时区内。它不在任何时区。历元值在所有时区中都相同。在这一瞬间,伦敦的毫秒值与纽约或旧金山的毫秒值相同。

如果未设置当前默认时区,则Date函数始终使用当前默认时区。所以对你来说,是的,本地机器时区是CDT。同样,CDT中的历元值与地球上其他地方的历元完全相同,因此当您的机器认为它处于中心时间时,没有真正的理由选择UTC。