Time 重启虚拟机时，系统时间不正确

自从将多个物理服务器虚拟化到GCP中以来，我就遇到了一个问题，即每当服务器重新启动时，时间都会提前几个小时（我认为是4小时，但可能是6小时）。我的本地办公室位于CST时区，这就是我们希望服务器显示的内容。在GCP中，虚拟服务器位于us-central1a区域。在虚拟服务器上，运行tzutil/g命令，它显示服务器设置为“中央标准时间”。如果单击工具栏上的时钟，然后选择“更改日期和时间设置”，它也会显示中心时区

服务器重新启动（并报告错误的时间）后，我可以通过单击“立即更新”选项（位于工具栏时钟、“更改日期和时间设置”、internet时间选项卡、“更改设置”“立即更新”（指向time server time.nist.gov）来更正时间

这个问题是在迁移到GCP之后才开始出现的，所以我认为这是一个计算引擎问题，而不是操作系统问题

有没有想过为什么会发生这种情况？我有关于迁移到谷歌云的所有4台windows服务器上都会发生这种情况的想法。三台是win2008r2，一台是Win2012r2

感谢任何可以帮助解决这个问题的帮助，因为我甚至无法重启而没有连接到服务器并检查/修复时间，我确实设置了一个启动脚本来延迟，然后在重新启动之后同步时间，但是它没有工作100%的时间，所以这是一个创伤性的创可贴。 我确实设置了一个启动脚本延迟，然后在重新启动后同步时间，但它没有100%的时间工作，所以这更像是一个创可贴

在这里，让这个脚本正常工作可能是解决方案。值得一提的是，您还需要在Azure和AWS上执行相同的操作，因为它们也使用相同的机制将Windows时区默认设置为UTC

• 请参阅上的AWS文档
• 有关Azure上Windows的类似问题，请参阅

通常，所有服务器都在UTC时间上运行，其客户端（应用程序、浏览器等）根据所在的位置设置时区，并由它们将UTC时间转换为所在的区域设置。（换句话说，您不希望拥有一百万个客户端连接的服务器必须跟踪每个客户端的时区才能正常工作）。在您的情况下，底线是服务器上需要自定义时区也需要自定义服务器配置，并且您看到的行为是经过设计的。这就是为什么您最好的办法是理解启动脚本为什么不能像您期望的那样工作

这些文档可能有助于参考：

---

如果查看GCP控制台中的VM实例日志，您会看到VM BIOS以UTC为单位报告时间

2019/10/3 14:9:44 Begin firmware boot time

一段时间后，BIOS移交给引导加载程序

2019/10/3 14:9:45 End firmware boot time
Booting from Hard Disk 0...

操作系统启动。在幕后，操作系统时间服务识别系统时区，然后设置时间并与时间源同步。从那时起，运行程序和服务将根据本地系统时间报告事件：

...
2019/10/03 09:10:05 GCEWindowsAgent: GCE Agent Started (version 4.6.0@1)

在Windows事件日志中，您应该看到时间服务的条目：

Log Name: System
Source: Time-Service
Level: Information

The time provider NtpClient is currently receiving valid time data from metadata.google.internal,0x1 (ntp.m|0x1|0.0.0.0:123->169.254.169.254:123).
The time service is now synchronizing the system time with the time source metadata.google.internal,0x1 (ntp.m|0x1|0.0.0.0:123->169.254.169.254:123).

在命令提示符中，您可以确保时间配置和状态正确：

C:\Users\user>systeminfo | find /i "Time"
System Boot Time:          10/3/2019, 9:09:49 AM
Time Zone:                 (UTC-06:00) Central Time (US & Canada)

因此，您不需要手动或与启动脚本同步时间。时间服务将为您完成：在启动后立即同步系统时间，并在启动后保持同步。

---

您只需为Windows设置正确的

时区

和

Internet时间服务器

，然后确保可以通过网络访问时间服务器。

您是否有“自动设置时间”功能“启用？感谢mebius99，我认为您将时间设置为UTC是正确的。我的服务器也正确设置为正确的时区，并指向可访问的时间服务器。这让我感到困惑，因为在我重新启动（时间变得不正确）后，我除了单击“立即更新”之外什么也做不了。”是的，当我运行命令“systeminfo | find/I”time时，它显示了系统的正确时区。mebius99，我听取了您的建议，并梳理了引导日志。所有GCP日志显示为CDT时间（如预期的那样），日志“time”writed详细信息显示了以下详细信息“2019-09-24 21:19:46-0500”，因此它似乎正在尝试以正确的时间启动，所有日志时间都显示相同的格式CDT-0500。正如我前面提到的，服务器设置为CST时间（UTC-0600）。我没有看到显示错误时间的GCE日志。只有在我从时间服务器重新同步时间之前登录到服务器时，时间服务才会正常工作：重新启动后，时间会同步。如果您不能等待时间同步周期完成，请登录到服务器并重试手动进行时间同步。因此不存在时间同步问题，对吗？Mebisu99，只有在系统重新启动后，时间才会变得不正确，并且在时间自动同步（稍后某个时间）之前，时间一直是错误的或者手动完成。我了解使用UTC时间的GCP服务器，然后将其转换为服务器所在的不同地区……但在我的案例中似乎没有发生这种情况。由于我的虚拟实例位于us-central1a区域，我原以为它会将UTC时间转换为该区域的实例ce是内置的（并且服务器配置了），此外，我发现我在云中构建的其他windows服务器（而不是虚拟化的物理服务器）很奇怪似乎没有同样的问题。我想我会继续调整脚本。不，我是说它不是根据服务器所在的位置翻译的，也不是应该翻译的。服务器所在的位置无关紧要，因为服务器应该