Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

ISO 8601 真的适合作为传输类型么?

  对于 Web API 设计中的时间格式这件事,我一直在推 ISO8601。可是自始至终都在遇到各种问题,于是我开始怀疑这个世界,到底是谁的错?在 JavaScript 中,对于日期时间格式传输的最佳类型莫过于 ISO8601,因为默认的 Date.prototype.toJSON 就是调用 toISOString。
  作为一个 JavaScript 的忠实拥护者,我当然希望完全使用 ISO8601。可是每次在和其他语言的开发者沟通时都非常累,比如 Python 中如果想 encode 和 decode 一个浏览器可以解析的 ISO8601 格式的时间就是非常困难的。而 PHP 5.5 虽然有自带的 DATE_ISO8601 这个模板常量,但它的定义本身都是有问题的。
  认真看看 ISO8601 就会发现,它的定义非常宽泛。我本来是希望 Web API 中的日期时间格式使用一种人类可读且不受时区影响的格式,可是 ISO8601 中只有一部分是如此,甚至不带时区信息的 Y-m-d 的日期格式也是规范的一部分。对于这么宽泛的一份规范似乎对程序完全没有约束力,这也难怪各个语言版本的实现都有如此大的差异。于是我渐渐无法理解 ISO8601 的设计思想了?
  有时候真觉得 Unix 时间戳虽然不是一种人类可读的格式,但它的通用性应该是我见过最强的了。只不过 Unix 时间戳无法描述毫秒,而且 JavaScript 使用的时间戳默认是毫秒级的,转换上会有点麻烦。
  这篇文章似乎并没有给大家解决什么问题,甚至我自己都纠结进去了。对于 ISO8601 这个问题吧,我希望将来会有更明确来把目前这凌乱的情况给整理一下。我依然希望在 Web API 中使用一种人类可读的日期时间格式,如果 ISO 实在不行,GMT String 也是可以考虑的。
网名:
54.144.24.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^