Java Date toString 包含一个时区...为什么?
我今天在 VB6 中编写了一些代码，它可以获得自 1970 年 1 月 1 日以来的毫秒数，因此我可以将值发送到 java 应用程序，该应用程序将解析该值，如 new Date(Long.parse(毫秒)).我知道 Date(Long) 正在寻找的毫秒数是自 GMT 纪元以来的毫秒数.我正在运行的机器在美国的 CDT 上.当我得到从毫秒解析的日期的 toString 值时，这是我得到的值:
I wrote some code today in VB6 which would get me the number of milliseconds since 1/1/1970, so I could then send the value off to a java application which would parse that value like new Date(Long.parse(milliseconds)). I understand that the milliseconds the Date(Long) is looking for is the number of milliseconds since epoch in GMT. The machine I am running on is on CDT here in the US. When I get the toString value of the date parsed from the milliseconds, this is the value I get:
Tue Aug 11 15:40:50 CDT 2015
CDT 就在那里，因为本地机器时区是 CDT?我只是认为 Date 的构造函数会假设从 GMT 纪元以来的毫秒数派生的日期将隐含在本地机器时区中，而不是偏移(在这种情况下)-5 小时，这有点奇怪.
Is the CDT just there because the local machines timezone is CDT? I just think its a little weird that the constructor for Date would assume that a date derived from the milliseconds since epoch in GMT would implicitly be in the local machines timezone, rather than being offset (in this case) by -5 hours.
推荐答案
CDT 就在那里，因为本地机器时区是 CDT?
Is the CDT just there because the local machines timezone is CDT?
用于显示的时区基于默认时区.
The timezone for display purposes is based on the default time zone.
日期中的毫秒是相对于纪元的，它没有自己的时区.
The millis in the Date is relative to epoch and it doesn't have a time zone of its own.
它是从格林威治标准时间 1970 年 1 月 1 日 00:00 开始拍摄的，或者如果您更喜欢 1969 年 12 月 31 日 17:00 CDT.
It is taken since 00:00 1/1/1970 GMT or if you prefer 17:00 12/31/1969 CDT.
将隐含在本地机器时区
使用当地时区仅用于显示目的.使用另一个时区或序列化 Date 并将其发送到另一个时区的机器，它将再次使用本地时区.
The use of the local time zone is for display purposes only. Use another time zone or serialize the Date and send it to a machine in another timezone and it will use the local timezone again.
相关文章