规约原文
10:13
13.【推荐】前后端的时间格式统一为"yyyy-MM-dd HH:mm:ss"，统一为GMT。
问题描述
- 如果不是针对格林尼治时区而只是针对零时区，这里最好写 UTC 而非 GMT
- 现实中存在更加健壮简单的标准，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）。
而这将带来巨量的开发和沟通成本。
修改建议
请使用标准格式及其推荐形式，不要自创格式。
规约原文
10:13
问题描述
我没有阅读完整的 ISO 8601 规范，但根据 Wikipedia 的内容，使用空格切分日期和时间是不允许的。
尽管在 RFC3339 中没有禁止(MAY)出于可读性等原因而使用其它字符比如空格，但许多程序并不能良好支持这种变体。而且这种表示没有被列举在附带的 ABNF 文法中(SHOULD)
且该规范似乎并没有允许省略时区字段
省略时区字段导致的问题
这个问题不能简单地以：“我没有国际业务，所以时区不重要”盖过。你没有跨时区业务，但是系统和其它程序给出的时间并不一定总是你所期望的时区。
丢弃时区字段会导致双方的迷惑，“我该以何种时区发送？”，“我该将这个时间点解释为何种时区？”。一切以 GMT 传递（尽管这本来就是不严谨的）仅仅是这篇手册的约定，在计算机系统中并没有形成广泛的共识（想想 java.time.LocalDateTime）。
而这将带来巨量的开发和沟通成本。
修改建议
请使用标准格式及其推荐形式，不要自创格式。