这不是特定于 Angular 的东西。 这是标准的JSON.stringify行为。

基本上，在发布数据时， $http将其转换为 JSON（通过JSON.stringify() ）。 在 JavaScript 中，Date 对象的 JSON 表示是它的 ISO-8601 形式（这是您在网络选项卡中看到的）。

一个 Date 对象无论如何都没有时区信息，所以没有信息被剥离。 当前区域设置（完全独立于 Date 对象表示的日期）具有时区偏移量，浏览器在console.log对其进行格式化时根据该偏移量格式化日期。

关闭，因为这不是 Angular 的问题。

@gkalpak首先，我认为说 Date 对象没有时区信息是不正确的。 当我们通过 new Date() 创建日期时，时区信息默认为本地时区。 Date 对象有getTimezoneOffset和toISOString方法。 当调用这些方法返回区域值时，浏览器对我们来说没什么好处，它们是 Date 对象中的实际值。

new Date().getTimezoneOffset()
-330

new Date().toISOString()
"2018-12-04T05:40:37.399Z"

其次， JSON.stringify()也不会剥离区域值，以下是我们在浏览器控制台中看到的，它是一样的，浏览器没有打印任何对我们有用的东西。

JSON.stringify({d:new Date()})
"{"d":"2018-12-04T05:42:08.973Z"}"

所以我仍然相信，如果 API 呈现一个没有这些毫秒值的 ISO 日期，并且 UI 使用一些仅选择日期并更改日期的日期选择器，那么在将日期发送回转换为 ISO 格式时，Angular 将不会有毫秒价值。

首先，我认为说 Date 对象没有时区信息是不正确的。

我仍然认为这样说是正确的 :grin: A Date对象 _"代表一个时刻 [...] 基于一个时间值，它是自 1970 年 1 月 1 日UTC 以来的毫秒数" _（来源： MDN ）。 因此，基本上每个Date实例只知道这个值，并且它的所有其他表示都是基于该信息加上区域设置/系统状态（例如时区偏移）而得出的。

#

Date 对象有getTimezoneOffset和toISOString方法。

这些是Date原型（来源： MDN ）上的方法，而不是Date对象（又名实例）本身的方法。

更具体地说， getTimezoneOffset()的值取决于当前区域设置（主机系统设置）。 这就是为什么没有等效的setTimezoneOffset()方法以及为什么同一系统上的所有Date对象为getTimezoneOffset()返回相同值的原因，例如：

const d1 = new Date('December 15, 2018 12:34:56');  // No timezone; uses the current system locale.
const d2 = new Date('December 15, 2018 12:34:56 GMT+10'); // Uses GTM+10 as timezone.

d1.getTimezoneOffset() === d2.getTimezoneOffset();  // true

因此，传递给Date的日期字符串表示中指定的时区信息仅用于解析该字符串并将其映射到如上所述的特定时刻。 结果Date对象对时区一无所知：笑脸：

toISOString()方法不会按照您的建议打印时区信息。 它只是在末尾添加Z ，表示UTC 。

#

其次， JSON.stringify()也不会剥离区域值

如上所述，它使用toISOString() ，它表示 UTC 中的日期值（因此在末尾附加Z以表示这一点）。 返回的字符串中没有时区信息。

#

所以我仍然相信，如果 API 呈现一个没有这些毫秒值的 ISO 日期，并且 UI 使用一些仅选择日期并更改日期的日期选择器，那么在将日期发送回转换为 ISO 格式时，Angular 将不会有毫秒价值。

我不知道毫秒与它有什么关系。 我们正在谈论时区信息。

同样，这与 AngularJS 无关。 这就是内置对象（例如Date和JSON ）相互交互的方式。