我从头开始启动 Linux 服务器 (Amazon Linux 2)。
我在东京地区，我像这样更改了时区信息；
ll /etc/localtime
# lrwxrwxrwx 1 root root 25 Feb 22 10:11 /etc/localtime -> ../usr/share/zoneinfo/UTC
# backup
sudo cp -p /etc/localtime /etc/localtime.org
# change timezone
sudo ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime
ll /etc/localtime
# lrwxrwxrwx 1 root root 30 Mar 10 22:06 /etc/localtime -> /usr/share/zoneinfo/Asia/Tokyo
现在以下内容已受到影响，比 UTC 早 9 小时，这对我来说似乎足够了。
- 'date' 命令的结果
- cron 作业的执行时间
- 守护进程的记录时间
然而，我在谷歌上搜索发现一些文章建议您还应该更改硬件时钟。
# default
cat /etc/sysconfig/clock
# ZONE="UTC"
# UTC=true
是不是修改这个文件比较好？
如果是这样，怎么办？什么会受到影响？
答案1
您发现的文章是“错误的”。按照 Linux 系统上的惯例，您将硬件时钟保留在统一时区（即 UTC），并且软件根据需要将硬件时间转换为本地时区。
周围"的“错误”只是因为这只是一个惯例。你也可以这样做，但它没有任何优点。相反，如果将其设置为本地时区，硬件时钟将必须执行诸如遵循夏令时之类的操作。通常，这不是您想要的，因为这意味着您需要每年更改硬件时钟两次。
嗯是的。保持系统时钟为 UTC。我不了解AWS，但虚拟机甚至无法更改硬件时钟提供的实际时间的情况并不罕见。
答案2
不是亚马逊特定的。我强烈怀疑亚马逊的硬件时钟是正确的，你应该只处理本地操作系统时区。但是，我提供了真实（或模拟）硬件时钟的所有信息。
- 了解现实世界中的 UTC 时间（如果您不确定：https://www.timeanddate.com/worldclock/timezone/utc）
- 验证您的硬件认为它是什么时钟：
sudo TZ=UTC hwclock --get - 检查您的操作系统认为时间是什么（UTC）：
date -u
步骤 1、2 和 3 中的时间应彼此一致。如果操作系统错误（步骤 3），则ntpdate pool.ntp.org.如果 hwclock 错误（步骤 2），那么sudo TZ=UTC hwclock -w -u （EC2 的模拟硬件时钟是否允许您更改它是一个有趣的问题 - 令人惊讶的是它确实如此）。
现在您可以检查您的硬件时钟所在的时区。
- 检查您的硬件时钟，就好像硬件时区是 UTC：
sudo TZ=UTC hwclock -u --get
如果返回近似的真实 UTC 时钟，则您的硬件时钟正在使用 UTC。如果它返回不同的值，则表明您正在使用本地时钟中的时区。我的偏见是，这从来都不是一个好主意，但也许某些第三方操作系统不同意（如果您是双引导，则在 EC2 上不太可能）。
现在，您终于准备好设置操作系统的时区，以便在查看日志时您可以了解它们实际发生的时间。您可以选择 UTC 并拥有一个共同的全球时间，以实现最高的理智。您可以选择服务器本地的时区，这使得来自其他可用区的日志需要在比较之前进行转换。您可以选择您所在的时区（并惹恼其他地点的同事）。在下面的示例命令中，我选择了 UTC。
ln -sf /usr/share/zoneinfo/UTC /etc/localtime
此时，date应该打印您选择的任何时区的时间。
/etc/sysconfig/clock 是一种在启动时重新创建符号链接（来自 /etc/localtime）的方法，但我认为大多数操作系统提供商已经考虑得更好并且不再这样做。我建议不要使用 /etc/sysconfig/clock 或者如果它存在，请确保它设置正确，并在重新启动后检查 /etc/localtime 是否仍然设置正确。
答案3
在某些时候，您将与计算机外部的服务器进行通信，此时您通常必须与他们就时间达成一致。这可能只是为了避免混淆，但通常是出于安全原因以避免重放攻击。因此，您的计算机应该知道 UTC 时间，否则您很可能会遇到麻烦。
您的硬件时钟应该尽可能准确地反映实际时间。如果我们比较我们的硬件时钟，你在伦敦，我在洛杉矶，我们的硬件时钟应该是相同的。我们当地时间显然会有所不同。