服务器 Gind.cn
  1. 服务器 Gind.cn
  3. 服务器上的本地时区被认为是有害的？
Intereting Posts
Amazon EC2实例 – 在sshterminal上发出“top”命令只是空白 将Windows XP guest虚拟机移动到新的虚拟机主机后的IRQL_NOT_LESS_OR_EQUAL Robocopy作业，将文件从VM Windows 2003复制到Windows 2008 DFS Share（通过WAN） 绕过“软件包configuration”屏幕 如何强制特定的应用程序安装在Fedora 17下的特定硬盘上？ 如何清理死信目录？ 如何使用当前的食谱模板目录，以循环的方式recursion复制所有模板与厨师 puppetdb的SSL问题 空文件夹需要inode phpMyAdmin端口需要改变 如果最近的事件日志事件超过一个小时，则使用Powershell触发一个操作 DNS区域和命名文件 Apache HTTP服务器 – 如何确定服务器上的下载是否完成以及哪个文件？ Win Server 2008 Standard上的Hyper-V 电子邮件代理循环

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

我很好奇其他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版本，希望今年晚些时候升级它不会成为问题。）