时间戳是否应始终使用UTC(如2012-06-14T10:32:11+00:00
)而非本地时间(如纽约的2012-06-14T06:32:11-04:00
)?
虽然不是WordPress问题,但我相信这将是一个很好的例子 - 由核心开发人员开发的WordPress核心,主题和插件,如果在某处输出时间戳,似乎总是使用像{{1 }}或get_the_date('c');
- 始终以UTC格式输出时间戳,如get_the_modified_date('c');
2012-06-14T10:32:11
。
我刚遇到this answer,它只是说“时间戳使用UTC。”
时间戳应该是UTC格式还是推荐的做法? (这两者之间存在很大差异。)基本上是这样的 - +00:00
- 错了? 2012-06-14T06:32:11-04:00
如何更好?
答案 0 :(得分:11)
时间戳肯定应以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 = new Date(utcInMillis);
console.log(utcAsDateObj);
//and that's how easy it is to restore to a date
//object from a UTC in millisecond format
一般来说,在有现代网络技术或类似选项的情况下,最不痛苦的事情是将所有内容存储为UTC,然后将时区严格地作为表示关注点。除了在当地环境中显示某个时间外,您不需要当地时间。
即使您在后端遇到一些愚蠢的非UTC时间戳,仍然值得在客户端通过在入口点转换并通过任何方式在退出点转换回来将UTC作为规范化选项可能。排序时区以及采用夏令时的地方以及被忽略的地方对DIY来说太麻烦了,如果你真的不得不触摸日期对象,那么它通常是不可避免的。实际上最终操纵/比较日期/时间。
没有更简单的方法来处理这个问题,而不是在将所有内容按照以毫秒为单位进行规范化的时候,直到你将它作为本地时间吐出页面为止。