英文原文：The 5 laws of API dates and times

比如说，你要树立你的第一个API，将它变成公共、个人、或一些混杂的产品。不要觉得诧异，假如你的第一个缺点是和日期/时间相干的，那末不要低估你可能当触及四处理日期和时代的时分所带来的费事。当触及四处理的日期和时间问题时，你可以出去看看。这里有一些技能可让你解脱这类潜伏的费事。

正告：我假定你运用公历。在国际场所，这多是一个蹩脚的假定。假如你在一个分歧的日历算法中操作，这不会协助你。

规矩 #1 运用ISO-8601格局作为你的日期格局

这是没有可会商的余地的。从W3C 到 IETF, 另有乃至 XKCD, 互联网不断运用这个规范。不要自作聪慧的运用其他。ISO-8601供给一系列的种类，来显示日期/时间/时区。

经过*nux把持台来疾速看看ISO-8601格局，输出以下号令：

ISO 8601 处理了非常多问题，包含：

• 天然排序 - 容易和优雅，免除过剩的任务便可完成排序
• 时区偏移 - 代表用户的地址和时区在日趋增加的全球化和Mobile天下中愈来愈主要。
• 地域中立性 - 想象一下恶梦普通的日期 2/3/4。这个日期跟着你所处美国，欧洲或者其他地方而有分歧的寄义...这个日期在美国代表Feb 3, 2004，或者在其他地方代表Mar 2, 2004。在ISO 8601条目中，2004-02-03去掉了这些模糊的可能性。
• 在分歧的编程言语中都失掉普遍的支撑 - 即便不是一切的言语都运用这个规范作为默许值（例如Java），可是它们根本都有成熟的库来转化 ISO 8601格局。不要自作聪慧来本人完成哦。

规矩#2： 承受任何的时区

如今你有一个ISO-8601的Tools了，但凭甚么你可以获得到有关时区的偏移数据呢，用它吧！我们在一个全球化的时期。特别是假如你的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平台的时分，它会对你的日期实行甚么操作。

我们大部分人都在分歧的时区或者国度任务，生涯或者交换，我们晓得连容易的布置一个约会都会让我们觉得有何等的迷惑。另有，假如你不盼望写一大堆日期转换和格局化的工具，你可能会盼望有一个规范来代表时间。好好应用这些规矩来处置你的日期和时间，你就能够减轻非常多懊恼。

本文中的一切译文仅用于进修和交换目标，转载请务必注明文章译者、出处、和本文链接。 2KB翻译任务按照 CC 协议，假如我们的任务有进犯到您的权益，请实时联络我们。

2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务