5 个关于 API 中日期和时间设计规则

比方说，你要建立你的第一个API，将它变成公共、私人、或一些混合的产品。不要感到惊讶，如果你的第一个缺陷是和日期/时间相关的，那么不要低估你可能当涉及到处理日期和时期的时候所带来的麻烦。当涉及到处理的日期和时间问题时，你可以进来看看。这里有一些技巧可以让你摆脱这种潜在的麻烦。

警告：我假设你使用公历。在国际场合，这可能是一个糟糕的假设。如果你在一个不同的日历算法中操作，这不会帮助你。

规则 #1 使用ISO-8601格式作为你的日期格式

这是没有可讨论的余地的。从W3C 到 IETF, 还有甚至 XKCD, 互联网一直使用这个标准。不要自作聪明的使用其他。ISO-8601提供一系列的品种，来显示日期/时间/时区。

通过*nux控制台来快速看看ISO-8601格式，输入如下命令：

ISO 8601 解决了很多问题，包括：

• 自然排序 - 简单和优雅，免去多余的工作即可实现排序
• 时区偏移 - 代表用户的地点和时区在日益增长的全球化和移动世界中越来越重要。
• 地区中立性 - 想象一下噩梦一般的日期 2/3/4。这个日期随着你所处美国，欧洲或者其他地方而有不同的含义...这个日期在美国代表Feb 3, 2004，或者在其他地方代表Mar 2, 2004。在ISO 8601条款中，2004-02-03去掉了这些含糊的可能性。
• 在不同的编程语言中都得到广泛的支持 - 即使不是所有的语言都使用这个标准作为默认值（例如JAVA），但是它们基本都有成熟的库来转化 ISO 8601格式。不要自作聪明来自己实现哦。

规则#2： 接受任何的时区

现在你有一个ISO-8601的工具了，但凭什么你能够获取到有关时区的偏移数据呢，用它吧！我们在一个全球化的时代。尤其是如果你的API是对外开放的，你将无可争议地要解决全球消费者的问题。不要去假设你的API使用者是用那个时区。

规则#3：用UTC（Coordinated Universal Time 世界同一时间）格式存储

这是大多数系统实际设计的一般规律。我已经记不清我看过多少次按照原公司总部时区建立的系统。不可避免的，除非你是纪律严明，用户最终不会用你的公司的时区看他们的时间。这很让人讨厌，尤其是当他们处在地球的另一端的时候。

UTC，或者世界标准时间，是最常见最有共性存储的时间，因为他不表示任何时区偏移量。这让你可以根据你系统的需要，给出整个系统时区的建议日期，无论是哪个时区都是恰当的。

规则#4 使用UTC格式作为返回值格式

UTC可以允许你的API调用者免去计算偏移到他们所需要的日期的工作。而对于你，更重要的是，你的API组不需要为每一次调用都去烦恼如何计算它的偏移值。在你的API文档和系统支持中，对于你如何处理日期，只需简单的说“你获取的是UTC格式”。

规则#5 如果你不需要时间的话，不要使用它

ISO 8601同样允许我们灵活的提供一个日期而不带时间。在时间不重要的场合中，只使用日期（例如“目标完成日期”）：不要保存或者返回时间。虽然对于只保存11:59pm没什么坏处，或者其他随机时间，但是，你可能在日期国际化的时候会碰到很大麻烦。

想象一下，你使用UTC格式保存2013-03-01T23:59:59，代表Mar 1，2013。现在，对于中国标准时间（UTC+0800）作时差计算，你现在是表示Mar 2, 2013 早上8点。这会有麻烦，因为日期被误读了。在这个例子中，我们只需要使用2013-03-01，不带任何时间/时区时差，来免除日期的解析误读的可能性。现在流行的数据库都支持只包含日期的格式。

总结

当所有这些关于日期的讨论可能会让你有点麻木，不过可以放心，几乎所有的RESTful平台都使用这些格式。当你需要摆弄数据序列化库的时候，需要当心，留意当它离开你的API平台的时候，它会对你的日期进行什么操作。

我们大部分人都在不同的时区或者国家工作，生活或者交流，我们知道连简单的安排一个约会都会让我们感到有多么的疑惑。还有，如果你不希望写一大堆日期转换和格式化的东西，你可能会希望有一个标准来代表时间。好好运用这些规则来处理你的日期和时间，你就可以减轻很多烦恼。

 

原文链接：http://web.itivy.com/article-432-1.html