问题描述
我今天在VB6中编写了一些代码，它将获得自1970年1月1日以来的毫秒数，因此我可以将值发送给Java应用程序，该应用程序将解析该值，例如 new日期（Long.parse（毫秒））。我知道Date（Long）所寻找的毫秒数是自格林威治标准时间以来的毫秒数。我正在运行的机器在美国的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小时。 p>
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.
推荐答案
用于显示的时区基于默认时区。
The timezone for display purposes is based on the default time zone.
日期中的毫秒数为
它是从格林尼治标准时间1970年1月1日开始，或者您更喜欢17： 00 12/31/1969 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.
这篇关于Java Date toString包含一个时区...为什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！