服务器上的本地时区被认为是有害的?

我很好奇其他pipe理员在远程pipe理服务器环境下的时区体验。 在我的职业生涯中,我遇到了几个约定;

  1. 始终,始终使用UTC。
  2. 总是总是使用基地总部所在的时区。
  3. 使用正在pipe理的人的当地时间。
  4. 使用服务器位置的本地时间。

在一些地方,我遇到了多个矛盾的约定。 我自己的喜好是一直使用UTC,没有夏令时。 但是出于某种原因,大多数人似乎更喜欢使用当地时间的一些概念,夏时制。 虽然这似乎是一个直截了当的技术问题,但围绕不断变化的公约总是似乎趋向于宗教分裂。

你在用什么? 你认为每种方法的优缺点是什么?

  • 硬件时钟应该始终是UTC。 总是。
  • 时区作为设置可以是任何方便的。 通常。 有时它也应该是UTC。

UTC很好的一些原因:

  • 夏时制规则改变,更新并不总是及时发生。 UTC使这消失。
  • 当需要比较不同位置的服务器的日志时,UTC是一个很好的通用标准。
  • 通常,当服务器位于不同位置时,人员或应用程序或两者都必须在执行数据库插入时处理时间转换。 如果你有一个单一的转换(到UTC),那么比起你必须从一个TZ转换到另一个TZ 容易得多,这是由服务器TZ决定的。

我更喜欢选项4.这是在服务器上运行的应用程序的责任,以决定是否存储DateTime值UTC或不。

另外,当服务器logging系统事件日志时,能够将本地事件与日志条目相关联是很好的。 例如,如果数据中心在当地时间报告networking中断,则可以轻松识别发生的任何问题,而无需在头上转换时间值。

不,不,一千次不。

有两种types的程序员……那些明白当地时间应该只用于显示/格式化的人,以及那些正在把自己画到一个angular落的人……他们正在用煤油绘画。

所有事件应以UTClogging,结果转换为本地时间仅显示给用户。 那些不能做到这一点的人是死心塌地的,那些使用本地时间的人会舍弃时区信息(我正在看 ,Oracle DBA)。

把它看作是一个污点检查…如果你把一个timespec转换成localtime,然后对它做任何事情,而不是把它发送到STDOUT,你的程序不仅要退出,而且还要删除一个致命的错误,你一个教训。

当给出的select,我喜欢保持在UTC的BIOS时钟,但实际的服务器时间本地时间。 我们没有多时区的存在,所以统一的日志时间戳并不是3M所面临的问题。

在我的公司,我们所有的服务器都在一个TZ直到今年。 我们现在有3个新的时区的服务器。 所有的服务器都运行在我们的本地时区。 这对于日志分析非常有用,特别是因为我们有分布在三个时区的网站。

但是,在一个特殊情况下 ,我们已经离开了一个服务器与我们的客户TZ。 应用程序应该在一天中的大部分时间,维护任务通常设置为在“夜间”运行。 起初,我们在TZ设置了服务器,但是维护任务对我们心爱的“我们睡觉时工作”的客户来说太慢了。

UTC也是一个非常好的select。 除非人们在查看日志时总是提到当地的时区(这里就是这种情况)。

我使用UTC运行所有服务器,并且尽可能快地转换任何进入我的控制权的服务器。

迄今为止的一个例外是星号服务器,我不得不在当地时间离开。 将其更改为UTC完全打破星号。 (1.6版本,希望今年晚些时候升级它不会成为问题。)