关于将系统时区设置为UTC的一些看法

2020-05-17 14:37:53

有些人主张将服务器上的系统时区设置为UTC,原因多种多样,您可以在一些Internet搜索中读到这些原因。一般说来,我没有那种经验让我对此有强烈的看法,但我确实知道的是,对我们来说,将系统时区设置为UTC而不是我们的美国/多伦多当地时间将是一个严重的错误。事实上,我认为我们是使用UTC作为系统时区的最坏情况的一个很好的例子。

我们、我们的服务器和我们的大多数用户都位于多伦多。我们系统的大部分使用是由多伦多当地时间(和多伦多工作周)驱动的,这意味着当我们要计划备份、ZFS快照或每日日志轮换等活动时也是如此。当用户向我们报告事情时,他们几乎总是使用多伦多当地时间(例如,我在上午10点出现了连接问题),而当他们不在多伦多时,他们通常不会使用UTC来报告。如果我们使用UTC作为我们的系统时区,我们所做的几乎所有事情都需要在UTC时间和本地时间之间进行转换;查看日志、安排活动、调查问题报告等等。使用多伦多当地的计时员,我们几乎从不需要这样做。

(当我们的服务器因停电、电源激增、互联网连接问题或其他原因而发生故障时,几乎所有关于它的报告和时间信息都将在多伦多当地时间,而不是UTC。几乎没有人在UTC报告与我们相关的事情。)。

考虑到这一切,应对一年两次的夏令时换班是一个很小的代价,从某种意义上说,不得不与之打交道是诚实的。毕竟,我们的用户经历了DST转换,他们的使用相对于UTC向前或向后移动了一个小时。

如果我们的服务器位于其他地方(例如位于ACTOLD的虚拟机),我们可能仍然会在多伦多当地时间运行它们。这样做的几乎所有原因仍然适用,尽管现在可能存在一些与它们所在的数据中心的本地时间相关的问题。

您越是偏离这一点,我就越怀疑将您的系统时区设置为UTC可能是有意义的。如果您的工作人员分布在世界各地,如果您的服务器分散在全球各地,如果使用量是连续的,而不是由一个地点或大陆驱动的,等等,我们的问题对您的影响就越小,UTC就越多地是中立时区。在UTC中运行软件也避免了保存来处理DST的时区转换,这意味着您不必测试它在DST转换时的行为,然后修复错误。

(软件有时无法避免处理堆栈中某个级别的DST移位,因为它会处理或显示人们感知到的时间,而人们肯定会感知到DST移位。但总的来说,为人们处理时间是一个棘手的问题,没有简单的解决方案。)