【发布时间】：2019-06-11 18:07:12
【问题描述】：
我们的前端只需要一个日期。我的理解是 JSON.NET 和 Web Api 的行业标准是 ISO 8601。是否可以在遵守 ISO 8601 标准的同时仅从我们的 Web Api 返回日期部分，或者我们的 JSON 对象的日期属性 (dateOfBirth)为了遵守 ISO 8601 标准，时间部分必须全为零吗？
【问题讨论】：
-
最常用的形式是
2004-12-15（年-月-日）。
【发布时间】：2019-06-11 18:07:12
【问题描述】：
ISO 8601 是一个指定许多不同格式的标准。第 4.1.2 节涵盖日期，第 4.2.2 节涵盖一天中的时间，第 4.3 节涵盖日期和时间的组合。该规范还为每个定义了“基本格式”和“扩展格式”。
一些基本格式的例子：
- 日期：
20190611 - 当地时间：
140000 - 日期和当地时间：
20190611T140000
一些扩展格式的例子：
- 日期：
2019-06-11 - 当地时间：
14:00:00 - 日期和当地时间：
2019-06-11T14:00:00
一天中的时间也有变化，为 UTC 添加 Z 或与 UTC 的特定偏移量，例如 -07:00。 （这些不适用于仅日期形式。）
因此，要直接回答您的问题，是的，您可以只传递日期。这仍然符合 ISO 8601，只要您使用上面显示的任何一种仅日期形式。 （JSON 响应通常选择扩展形式。）
顺便说一句，这不仅仅是一种选择，而是一种最佳做法。仅日期值（例如出生日期和其他周年日期）不应附加时间 - 即使它全为零。这样做会扭曲他们的意思。
也就是说，请注意一些陷阱：
- 某些平台没有内置的仅日期数据类型，并且会分配午夜。
- JavaScript 的
Date对象（通过 ECMAScript 标准）偏离 ISO 8601 并解析仅日期值，就好像它们在 UTC 午夜而不是当地时间午夜一样。因此，如果您从网页调用 API，您可能希望自己解析值，或者使用库，或者将它们保留为字符串而不是Date对象。 - 某些时区在午夜有前向转换的日子（例如 DST），这意味着时钟从 23:59:59 到 01:00:00。如果你指定午夜，一些实现会前进，一些会后退，还有一些会出错。
如果您必须将仅日期值解析为日期时间数据类型，避免这些问题的一种方法是分配中午 (12:00) 而不是午夜 (00:00)。
此外，您可能需要确保 ISO 8601 确实是您需要遵守的标准。很多人说 ISO 8601，其实是指RFC 3339。 RFC 3339 主要符合 ISO 8601，但只定义了日期 + 时间 + 偏移量配置文件。因此它适用于时间戳，但不适用于整个日期。
【讨论】：