在JSON中存储日期/时间的最佳方法是什么?

zga*_*ll1 15 json types date

我是JSON的新手,在审查JSON规范时,我注意到日期和时间没有数据类型.我做了一些研究,并提出了一些建议,其中一个是使用UNIX时间戳.这是最简单的方法吗?我会遇到任何问题吗?

小智 29

我建议使用ISO 8601日期.特别是这种格式

2014-03-12T13:37:27+00:00
Run Code Online (Sandbox Code Playgroud)

可以跨多种编程语言移植.

编辑:

JSON只知道这些类型:

string
number
object
array
true
false
null
Run Code Online (Sandbox Code Playgroud)

日期和日期时间最好以广泛使用的格式存储为字符串.

  • 那么你只是将日期存储为字符串吗? (2认同)

mat*_*tpr 6

我想最好的答案取决于使用该日期/时间的上下文。

TL/DR;

正确的格式取决于...

  • 数据使用方式的上下文(参见下面的示例)
  • 人或代码是否正在使用 json 以及您的编程语言或库是否轻松支持特定格式。

我建议使用 json 数字(unix 时间戳),然后根据用例将它们与用户时区或单个单独存储的“渲染时区”(json 字符串)组合。这允许向用户呈现最相关的日期/时间呈现,并允许您根据用户的位置/区域设置轻松使用不同的日期/时间格式。

或者,如果人类的 json 可读性对您来说很重要,您可以使用 ISO 字符串格式,但仍然在代码中进行解析和时区转换,以最大程度地灵活性呈现用户友好的日期/时间。

警告如果您手写这些时间戳,请不要弄乱它们。不同时区的偏移量在一年中不同地区的不同日期会发生变化,如果您为给定区域/日期放置了错误的偏移量,那么您的时间戳将不会代表正确的时间点......并且当您解析它并格式化时否则您可能会遇到时间显示错误的问题。

如果您希望 JSON 日期易于人类阅读

即,如果您希望人们直接读取 json 并使日期/时间有意义。

在这种情况下,@Ribtoks 的答案可能是最好的。尽管如果日期/时间存储在与用户不同的时区中,用户可能会感到困惑和/或需要在他们的头脑中进行时区转换以便正确解释日期/时间。

人类手动编辑和格式错误的诱惑更大,这将导致解析错误。此外,不正确的 UTC 偏移量(给定区域/日期的偏移量/时间错误)将导致格式化后向用户显示错误的日期/时间。

如果json只是数据存储,日期/时间将通过代码渲染

用户本地日期/时间格式

即您想要向用户显示本地时区的特定时刻(日期/时间)。

在这种情况下,除了表示特定时刻的日期/时间数据之外,您还需要一种方法来确定给定用户(不同主题)的“正确”时区。

您的代码需要解析/转换 JSON 日期/时间数据,以便可以将其与用户的时区数据(例如America/DenverEurope/Berlin)结合起来,以用户友好的方式打印格式。看看moment-timezone图书馆吧。

例如时间点:
December 31, 2020 8:00 PM America/Denver

January 1, 2021 4:00 AM Europe/Berlin

对于社交媒体、博客文章或留言板等内容,这种类型的行为通常是可取的,用户想知道某些内容是在他们自己的当地时间发布的,而不关心作者的时区。

在这种情况下,由于我必须解析/格式化日期/时间,所以我通常将日期/时间存储在unix时间戳(整数...json数字)中。

获取一个数字并对其进行数学计算比解析包含内置时区的字符串时间戳更简单,以便了解底层的特定时刻,然后为不同时区的用户格式化新的日期/时间字符串。

事件/位置-本地日期/时间格式

即您想向特定时区的用户显示特定时刻(日期/时间)。

示例:柏林(现场)音乐会的日期/时间。如果您有音乐会观众在伦敦购买门票,那么向他们显示音乐会在伦敦时间开始的时间会很混乱,因为他们将在柏林参加活动。

这与上面的“用户本地”情况相同,不同之处在于,您无需在不同时区中为每个用户格式化/呈现特定时刻,而是在单个特定“事件位置时区”中呈现日期/时间”。

因此,除了存储特定的日期/时间之外,您还应该存储要在其中渲染该日期/时间的时区。

虽然您可以将日期/时间预先格式化为字符串,但这为您提供了更少的以编程方式(即使用代码)更改日期格式的选项。例如,您可能想要使用事件本地时区,但对不同国家/地区的用户使用不同的日期/时间格式。

例如,2020 年 11 月 25 日晚上 7 点在柏林举行的音乐会。同一时间、同一时区,但格式不同。

美国
11/25/20 7:00PM Europe/Berlin
德国
25.11.20 19:00 Europe/Berlin
英国
25/11/20 19:00 Europe/Berlin

因此,在这种情况下,我还将日期/时间存储为 json 数字(unix 时间戳),然后还将事件时区存储为该时间戳旁边的字符串。这使得解析/时区转换计算更加简单。然后,您仍然需要找出用户的特定日期/时间格式首选项(浏览器区域设置、用户配置文件等......超出了这个问题的范围)。

关于时区/偏移错误的轶事

我有一位同事在他的计算机上设置了错误的时区(导致他所在位置的 UTC 偏移量错误)。

为了解决这个问题,他禁用了网络时间并手动调整计算机时钟以纠正错误的时区。

当他发送特定时间的会议邀请时,邀请包括时间和该时间的时区...当然,当您跨时区边界进行呼叫时,这一点很重要,这样每个人都可以在本地时间看到会议并拨打电话-同时进入。就我同事而言,这些会议当然是在不同的时区举行的。

他很生气,因为每个人都错过了一个小时的会议,并向我们展示了他如何安排下午 3 点的会议,但我们都收到了下午 4 点的邀请。

故事的士气……黑客通常最终会适得其反,因此确保您及时存储了正确/预期的时刻非常重要。您始终可以更改稍后显示的特定时间点的时区/格式,但前提是您首先存储了正确的时间点。

在处理表单输入时,获取正确的基本时间点通常会发挥作用(例如,日期选择器给出 YYYY-MM-DD,时间选择器给出 HH:MM)。您需要确保根据用例使用时区上下文解释这些来自用户的日期/时间输入字符串。