我正在调查涉及将序列化UTC日期转换为JavaScript日期对象的问题;我已经阅读了关于这个主题的几个问题，但我仍然不清楚。
首先让我说我在英国。如果我采用UTC时期1473805800000，即Tue, 13 Sep 2016 22:30:00 GMT，则使用该值创建JavaScript日期：
var date = new Date(1473805800000);
console.log(date);
控制台记录：
Tue Sep 13 2016 23:30:00 GMT+0100 (GMT Summer Time)
即。浏览器已经认识到需要为DST添加额外的小时。
我的问题是，如果我在10月30日之后再次运行相同的代码，那么时钟已经回来了，我是否仍会得到23:30的相同结果，或者它是22:30，好像它是格林威治标准时间？换句话说，浏览器是否添加了一小时，因为主题日期是DST，或者因为我们目前处于夏令时？
我无法按照组策略更改工作站的系统时钟，否则我会及时跳过它并自行测试。
答案 0 :(得分：6)
Javascript Date对象使用的时间值是自1970-01-01T00：00：00Z以来的偏移量（以毫秒为单位）。它始终是UTC。
如果Date构造函数被赋予单个数字参数，则将其视为UTC时间值，因此无论系统时区设置如何，都表示相同的时刻。
使用console.log(date)时，会调用内置的 toString 方法生成依赖于实现的字符串，通常使用主机系统的当前时区设置来创建方便的，人类可读的字符串。
系统中的当前夏令时规则用于确定用于＆＃34; local＆＃34;的偏移量。时间，因此如果日期从夏令时适用的时间变为不适用的时间，则会同样调整时区偏移（请注意，夏令时偏移不总是1小时）。当前系统偏移量无关紧要，使用的是基于时间值所代表的日期和时间的设置。
此外，Date对象非常简单，它们只是一个时间值。时区偏移来自系统设置，它不是Date本身的属性。
所以，给定：
我的问题是，如果我在30日之后再次运行相同的代码 十月时钟已经过去了，我还会得到同样的结果 结果是23:30，还是22:30好像是格林威治标准时间？
答案是＆＃34;是＆＃34;，自BST 9月13日起，它仍将是23:30。运行代码时无关紧要，只是该日期的系统偏移设置。
答案 1 :(得分：1)
在您的情况下，日期是使用纪元1473805800000创建的，并转换为您的时区GMT + 0100。 Epoch始终为UTC时间，因此它被读取为UTC并转换为您当前的时区。
2016年9月13日，GMT + 01有夏季时间，因此在微积分中被考虑。
就我而言，我得到以下内容，运行与您相同的代码：
Thu Sep 15 2016 14:13:14 GMT-0300 (E. South America Standard Time)