Unsolved

1 Rookie

 • 

1 Message

 • 

4 Points

8

August 23rd, 2026 12:22

Windows time remains synchronized but browser calculations differ

Hello,

I'm troubleshooting a strange issue on two Dell Windows systems with nearly identical configurations.

Both machines:

  • Use Windows 11
  • Have automatic time synchronization enabled
  • Show the same timezone and regional settings
  • Run the same browser version    ascendant

However, when testing applications that rely heavily on user-entered date and time values, the calculated results occasionally differ between the two systems.

I have already verified:

  • Windows Update status
  • Time synchronization service
  • Regional settings
  • Browser settings
  • System clock accuracy

Before I start investigating deeper, I'd like to understand whether anyone has encountered similar behavior on Dell systems.

Specifically:

  • Can Dell BIOS time settings affect browser-based calculations even when Windows time appears correct?
  • Are there known issues involving timezone synchronization after sleep or hibernation?
  • Is there a recommended diagnostic process for verifying that system time and locale information are being interpreted consistently across applications?

Any suggestions would be appreciated.

Thank you.

1 Rookie

 • 

17 Posts

 • 

48 Points

August 23rd, 2026 16:07

@halescane 

On Dell systems, the BIOS/RTC time itself does not directly affect browser-based date/time calculations as long as Windows is reporting the correct local time and time zone to applications. Differences like you’re seeing almost always come from time zone / DST interpretation, location-based automatic time zone, or subtle locale/region mismatches rather than the BIOS clock.

Even with the same Windows version, browser, and visible settings, these factors can cause different results in web apps that rely on user-entered date/time:

Time zone vs. displayed clock time
Windows can show the same wall-clock time while using different underlying time zones or DST rules, which changes how JavaScript Date objects are interpreted. Community threads and Microsoft Q&A show cases where Windows “keeps changing back” to a different time zone or uses an incorrect one despite the clock looking right.

“Set time zone automatically” and location services
If one machine has location-based time zone enabled and the other doesn’t (or they detect location differently), they may apply different offsets or DST transitions, especially around sleep/hibernate or after travel. Guidance for Windows 11 explicitly calls out checking location services and automatic time zone settings when times behave inconsistently.

Regional format / locale differences
Two systems can have the same time zone but different Regional format (e.g., en-US vs en-GB vs custom), which affects how date strings are parsed in browsers and thus how calculations turn out. This is often overlooked when only “Time zone” and “Clock” are checked.

Sleep/hibernate and time sync timing
After sleep/hibernate, one PC may resync its clock immediately via Windows Time, while the other lags or uses a cached offset, leading to brief mismatches that can affect time-sensitive web apps. Docs on Windows Time service and common fixes highlight restarting w32time and verifying NTP behavior after such events.

Dell BIOS time affect browser calculations.
The BIOS/RTC provides the hardware clock, but Windows reads it at boot and then manages time via the Windows Time service (w32time). Once Windows is running and synchronized, browsers and other apps use the OS-reported time and time zone, not the BIOS directly.

BIOS issues usually manifest as systematic clock drift or wrong time after power loss, not as two machines with identical Windows time showing different calculation results in a browser. If both PCs show the same correct time in Windows, BIOS differences are unlikely to be the cause.

Recommended diagnostic process
To verify that time and locale are interpreted consistently across the two Dell systems:
Confirm exact time zone and DST rules
Settings → Time & language → Date & time:
Ensure Time zone is identical (not just the clock time).
Temporarily turn Set time zone automatically Off on both and manually select the same named zone.

Check location-based time zone
Settings → Privacy & security → Location:
Ensure Location services and app permissions (especially “Windows Shell Experience”) are either both enabled or both disabled, and that location detection is consistent.

Verify regional format and locale
Settings → Time & language → Language & region → Regional format:
Make sure both use the same format (e.g., English (United States) vs English (India)) and check Change formats for date/time patterns. Mismatched formats can change how browsers parse ambiguous date strings.

Validate Windows Time service behavior
Run in an elevated terminal on both:
w32tm /query /status
w32tm /query /configuration
w32tm /resync
Ensure the service is Running and using the same NTP source; restart it (net stop w32time / net start w32time) if needed, especially after sleep/hibernate.

Compare browser environment

In the same browser version on both PCs, open a test page that logs:
new Date().toString()
new Date().getTimezoneOffset()
Intl.DateTimeFormat().resolvedOptions()
Any difference here explains divergent calculations even if the taskbar clock looks identical.

Test after sleep/hibernate
Put both systems to sleep/hibernate, wake them, and immediately re-check the values in step 5. If they diverge only after sleep, focus on time sync timing and location-based time zone behavior.

No Events found!

Top