规约中有关前后端接口日期时间传递的约定是在挖大坑

[iseki0]

规约原文

10:13

13.【推荐】前后端的时间格式统一为"yyyy-MM-dd HH:mm:ss"，统一为GMT。

问题描述

1. 如果不是针对格林尼治时区而只是针对零时区，这里最好写 UTC 而非 GMT
2. 现实中存在更加健壮简单的标准，RFC3339，或者更全面的标准 ISO8601 。这里没必要自创格式，还是个有缺陷的格式（下文将说明这个格式有什么问题）

我没有阅读完整的 ISO 8601 规范，但根据 Wikipedia 的内容，使用空格切分日期和时间是不允许的。

Separating date and time parts with other characters such as space is not allowed in ISO 8601 (Wikipedia)

尽管在 RFC3339 中没有禁止(MAY)出于可读性等原因而使用其它字符比如空格，但许多程序并不能良好支持这种变体。而且这种表示没有被列举在附带的 ABNF 文法中(SHOULD)

ISO 8601 defines date and time separated by "T". Applications using this syntax may choose, for the sake of readability, to specify a full-date and full-time separated by (say) a space character. (RFC3339 Page 8)

且该规范似乎并没有允许省略时区字段

省略时区字段导致的问题

这个问题不能简单地以：“我没有国际业务，所以时区不重要”盖过。你没有跨时区业务，但是系统和其它程序给出的时间并不一定总是你所期望的时区。
丢弃时区字段会导致双方的迷惑，“我该以何种时区发送？”，“我该将这个时间点解释为何种时区？”。一切以 GMT 传递（尽管这本来就是不严谨的）仅仅是这篇手册的约定，在计算机系统中并没有形成广泛的共识（想想 java.time.LocalDateTime）。
而这将带来巨量的开发和沟通成本。

修改建议

请使用标准格式及其推荐形式，不要自创格式。

[iseki0]

请不要以前端方便展示为理由进行反驳，就算不去讨论什么是前端以及前端的职责是什么，这里使用的是GMT，我不认为你应该在面向各种地区的程序中都使用 GMT 作为时间时区，这种反驳理由并不成立。

[zengxuebin]

我司有国际业务，可市区设置的仍然是GMT-8，正常吗？

[iseki0]

我司有国际业务，可市区设置的仍然是GMT-8，正常吗？

这不重要，传输时正确携带了自然时区，应用程序就理应能够正确处理。至于终端到底该以什么时区展示，日期该以何种时区计算，这得看业务，听你家产品的。

[zengxuebin]

谢谢

[GuguAbrams]

"created_at": "2023-10-14T13:18:48+08:00"

[zqq90]

附议

[gongjimin]

OpenAPI 3.0按说挺不错的，但好像国内不太吃香？
OpenAPI 3.0要求时间采用RFC3339

[zqq90]

@RussiaVk @dengchuncui
有何高见