12

时间戳是否应该始终使用 UTC（如2012-06-14T10:32:11+00:00）而不是本地时间（如2012-06-14T06:32:11-04:00纽约）？

参考

  1. 虽然不是 WordPress 问题，但我相信这将是一个很好的例子——核心开发人员开发的 WordPress 核心、主题和插件，如果在某处输出时间戳，似乎总是使用类似get_the_date('c');or的东西get_the_modified_date('c');——它总是以 UTC 格式输出时间戳，如2012-06-14T10:32:11+00:00。

  2. 我刚刚遇到了这个答案，它简单地指出“时间戳使用 UTC”。

问题

时间戳应该是 UTC 还是只是推荐的做法？（两者之间有很多区别。）本质上是这样的2012-06-14T06:32:11-04:00--错了吗？怎样2012-06-14T10:32:11+00:00更好？

4

1 回答 1

17

时间戳当然应该以 UTC 格式存储。日期的格式取决于该时区的要求。时间戳通常以 UTC 格式存储，因此显示到其他时区的转换更容易且可能。

通过仅将时间戳作为 UTC 存储在数据库中，您可以有效地将时区仅作为视图关注点。所有关于时间比较的数学和逻辑都可以假设在全球范围内同步。剩下的只是客户知道它在哪里，它在哪里的规则是什么，然后只是吐出结果。例如，通过 Chrome 开发者控制台在 JavaScript 中：

var dateObj = new Date();

console.log(dateObj);
// spits out local time
// if you and 23 other people in every time zone across the planet created
// a date object simultaneously you'd all see a different number
// adapted to your local time zones

var utcInMillis = dateObj.getTime();
// gives UTC in milliseconds.

console.log(utcInMillis);
// if you and 23 other people in every time zone across the planet created
// that same date object `dateObj` simultaneously you'd see the same number

console.log(new Date().getTime() - utcInMillis);
// how many milliseconds passed since utcinMillis was recorded and now

var utcAsDateObj = 新日期（utcInMillis）；控制台.log(utcAsDateObj); //这就是从UTC以毫秒格式恢复到日期//对象是多么容易

一般来说，在有现代 Web 技术或类似选项的情况下，最不痛苦的事情是将所有内容存储为 UTC，然后将时区严格作为一个表示关注点。除了在当地环境中显示某人的时间外，您不需要任何本地时间。

即使您在后端遇到了一些愚蠢的非 UTC 时间戳，仍然值得通过在入口点转换并在出口点以任何可能的方式转换回客户端，使 UTC 成为您在客户端的规范化选项。整理出时区以及在哪些地方采用夏令时以及在哪些地方忽略它对 DIY 来说太混乱了，如果你真的必须触摸你需要变得更花哨的日期对象，这通常是不可避免的最终实际操作/比较日期/时间。

没有比将所有内容规范化为 UTC （以毫秒为单位）更简单的方法了，然后您将其作为当地时间在页面上吐出。

于 2012-06-14T17:18:02.593 回答