[BUG] - Fresh install of Atlas v0.5.0 (hotfix) sets Windows Time Service to Manual, causing incorrect system time in China

[Newblackmask]

Before continuing...

• I agree to follow Atlas' Code of Conduct
• I have searched our issue tracker to verify that the issue hasn't been reported already
• I have searched the Atlas documentation beforehand for a solution
• I am on the latest version of Atlas, and didn't do an unsupported upgrade

Description

Environment

OS: Windows 10/11 (Chinese region / UTC+8)
Atlas Version: v0.5.0 (hotfix) — Fresh install (not an update)

🐛 Problem Description

After a fresh installation of Atlas v0.5.0 (hotfix), I noticed that the Windows Time Service (W32Time) was automatically changed from Automatic → Manual startup.

As a result, my system time and date are completely wrong (not matching China timezone UTC+8).
🔧 What I've Tried

I asked AI for help and manually set the Windows Time Service back to Automatic startup:

services.msc → Windows Time → Startup type: Automatic → Start

However, it almost has no effect. After every reboot, the service goes back to Manual, and the system time is still incorrect.
📍 Expected Behavior

The Windows Time Service should remain Automatic after a fresh Atlas install, so the system can correctly sync time with NTP servers (e.g. time.windows.com or cn.pool.ntp.org) and display the correct China timezone.
🙏 Request

Please fix this in the next patch.
— A user from China 🇨🇳

Steps to reproduce

Fresh install of Atlas v0.5.0 (hotfix) sets Windows Time Service to Manual, causing incorrect system time in China.

Expected behavior

The Windows Time Service should remain Automatic after a fresh Atlas install, so the system can correctly sync time with NTP servers (e.g. time.windows.com or cn.pool.ntp.org) and display the correct China timezone.

Actual behavior

After a fresh installation of Atlas v0.5.0 (hotfix), I noticed that the Windows Time Service (W32Time) was automatically changed from Automatic → Manual startup.

As a result, my system time and date are completely wrong (not matching China timezone UTC+8).

Atlas Version

Atlas v0.5.0 for Windows 11 25H2

Desktop information

Processor-AMD Ryzen 7 6800H with Radeon Graphics
GPU--NVIDIA GeForce RTX 3050 Laptop GPU
RAM--16 GB
Storage--512 GB SSD
Drivers--All up to date (latest)

Additional content

This issue is software-related and has nothing to do with hardware specifications.

[Stensel8]

Just to add some context here:

On standalone Windows 10/11 systems, the default startup type for the Windows Time (W32Time) service is Manual (Trigger Start), not Automatic. Even if you manually set it to Automatic, Windows can revert it back to Manual (Trigger Start) after a reboot – this is by design since Windows 7 / Server 2012 R2 to reduce always‑running services and improve boot performance and power usage. See for example documentation summarized here:
https://www.urtech.ca/2022/06/solved-should-the-windows-time-service-be-set-to-automatic-start-or-manual/

In the Atlas playbook, the config-time tweak only:

• starts the w32time service once, and
• runs w32tm /config + w32tm /resync to configure NTP and sync the clock.

It does not change the startup type of the Windows Time service to Manual or Automatic. That part is controlled by Windows itself, and on non‑domain machines the service is expected to be Manual (Trigger Start).

Because of that, what you are seeing (service shown as “Manual” after a reboot, and time still incorrect) is very likely:

• normal Windows behavior for the service startup type, combined with
• a separate problem where time sync itself is failing (for example because of NTP reachability or regional network issues from China).

There is a similar user report against another tweak tool (Chris Titus Tech’s WinUtil) where changing tweaks led to confusion around the Windows Time service and time sync:
ChrisTitusTech/winutil#4278

So this doesn’t look like an Atlas regression that explicitly sets W32Time to Manual, but rather standard Windows behavior around Manual (Trigger Start) plus time sync failing in your environment.