这是一个很小也很简单的事情，有些软件工程师可能不清楚，但是把时间戳格式理解清楚对每个开发工程师是很重要的一件事。

前段时间内我们在构建一个项目，对于时间戳的格式我们进行了一次激烈的争辩。我们面临的问题是我们的时区不固定，所以，经过一番争论，对于我们的时区处理问题我们达成了一致的意见。

我们最终决定使用RFC 3339作为我们的时间戳标准，前端和后端使用这个格式用于日期的传递。当然，我们也一致同意使用UTC(0时区)作为默认时区，即使不涉及前端的交互，纯粹后端服务间的交互也将UTC作为默认时区。以此为基础，各个前端或后端根据自己的需要自己的时区转化时间。

那么，什么是 RFC 3339?

RFC 是Request For Comment的缩写，是经IETF(Internet Engineering Task Force )起草和审核的官方文档.

该委员会已经发布了许多RFC文件。 并成为各个领域的标准。 他们的文档之一是RFC 3339，它是DateTime格式的文档。 

通常，如果您查看RFC文档，则它主要讨论有关DateTime格式的问题，总而言之，您将看到建议的DateTime格式如何，如以下示例所示。

2019-10-12T07:20:50.52Z

没错，就是那样。

但是有一个问题。 对于日期时间格式，ISO已经对其进行了标准化。 它是Datetime的ISO 8601标准。 对于已经熟悉ISO 8601的人们，RFC 3339非常相似。 有什么不同？

因此，如果您再次查看RFC文档。 RFC 3339使用/遵循Internet日期时间的ISO 8601配置文件。 在第5.6章中有明确规定

因此，实际上，Date ISO 8601之间没有什么大的差异。使这两个不同的唯一小事情是日期和时间之间的“ T”语法。 ISO 8601使用“ T”字符分隔日期和时间。 在RFC 3339中，可以仅使用空格替换“ T”字符。

例如：

# This is acceptable in ISO 8601 and RFC 3339(with T)

2019-10-12T07:20:50.52Z

# This is only accepted in RFC 3339(without T)

2019-10-12 07:20:50.52Z

 因此，总体而言，它仍与ISO 8601相同。

了解时区

当我向我的密友询问RFC 3339时，我感到有些震惊，没人知道这一点。 即使对于ISO 8601，也只有少数几个人知道这方面的细节。

尤其是读取TimeZone格式。 从我10个朋友中，我只能听到1个关于时区格式的信息。

2019-10-12T07:20:50.52Z

看看上面的例子。 当我问某人时，他们会说这是雅加达时间2019–10–12 07：20：50.52，因为我们住在雅加达。 因此，他将认为这是雅加达的时间。 但这是错误的。 因为如果将时间转换为雅加达时间，则应该是：2019-10-12 14：20：50.52。

这怎么可能？ 我怎么能说这个例子的雅加达时间应该是2019-10-12 14：20：50.52？

在RFC 3339中，我们还可以从格式中了解时区。 它以“ Z”语法显示。 “ Z”表示UTC + 0。 “ Z”代表祖鲁时区，与GMT或UTC相同。 因此，如果将Z放在DateTime上，则表示其时区为UTC + 0。

更详细的例子：

2019-10-12T07:20:50.52Z (UTC+0)

2019-10-12T07:20:50.52+00:00 (UTC+0)

2019-10-12T14:20:50.52+07:00 (UTC+7)

2019-10-12T03:20:50.52-04:00 (UTC-4)

查看粗体文本。 它将说明如何以DateTime格式编写时区。

它为什么如此重要？

这对于处理来自多个时区的请求非常重要。 如果您的应用程序仅接受与您的时区相同的请求（目前），那么工程师可能对此并不满意。

对于工程师来说，为什么即使像Golang这样的几种编程语言都已经能够处理这个问题，这又为什么真的那么重要呢？ 这是因为有时工程师对它不太了解，并且可能以后会带来新的问题。

让我告诉你一个故事。

因此，我将举例说明为什么这确实很重要。 我和我的朋友最近才发生这种情况。 我们有一个有关待处理交易的问题，我们需要进行检查和验证。

在我们的应用程序中，我们使用UTC + 0，他（我的朋友）知道这一点。 因此，要修复待处理的交易，我只需要获取交易发生时的详细信息，并检查是否有另一笔交易在待处理交易周围，并在那时重新验证所有待交易。

问题是，当我问到数据库中该行的事务处理时间（创建时间）时。 他会自动将小时自动加7(我们的时区UTC + 7)，但不会更改时区格式。 而且，这给我带来了更多时间来验证该时间段内所有打算进行的交易。 因为我查询的DateTime范围错误。

例如

#This is our datetime stored in DB

2019-10-12T07:20:50.52Z

然后我通过聊天请他告诉交易时间。 他把这个给我。

# He add the hour with +7 but not change the timezone

2019-10-12T14:20:50.52Z

这错在哪里呢？ 看“小时”值。 他添加了7并将其发送给我。 但是时区仍然是“ Z”（UTC + 0）。 由于我知道要阅读RFC 3339，因此我认为这是UTC + 0，因为他将其写为“ Z”。

而且，在那个日期时间，我正在对数据库进行一些查询。 但是，我得到的并不是我想要的。 当我尝试按ID查询时，显示的内容与他给我的显示内容有所不同。 恐怕数据库有更新查询，导致查询结果与他提供给我的查询有所不同。

这给我带来了困惑。 为了验证这一点，我再次问他，你发过来的时间真的是UTC + 0时区的吗？

他说，他已经将小时加了+7。 而且我感觉像一坨屎。 🤯

然后，我对他说，增加小时数时，也请更改时区。 因此，不会混淆谁会读日期时间。

因此，如果我们更改前面的示例以使用时区UTC + 7进行更正，则应该像这样

#This is our datetime stored in DB

2019-10-12T07:20:50.52Z

#This is how it should be converted to UTC+7

2019-10-12T14:20:50.52+07:00

号外

对于工程师来说，了解格式以避免数据不一致是非常重要的事情。 幸运的是，根据我的经验，阅读给定日期时间的人仍然很安静。 如果有一个应用程序会读取日期时间，那么会有很多不一致的数据，因为我们手动添加了错误的时区。

因此，这里有一些要点：

“ Z”：代表零时区（UTC + 0）。 等于RFC 3339中的+00：00。

RFC 3339遵循ISO 8601 DateTime格式。 唯一的区别是RFC允许我们用“空格”替换“ T”。