Microsoft breaks timezones in Settings and calls on an unlikely ally for help As its Ignite conference kicks off, Microsoft is admitting there is another known issue with Windows 11 24H2. If you try to change the time zone, you might find it a challenge. The problem lies in Microsoft's shiny new Windows Settings app. Users without administrative privileges might not be able to change the time zone, …
It would also be a good idea to avoid pondering why a setting that only Administrators can access in the Windows Settings app can be changed via the legacy Control Panel.
Because the levels upon levels of crud and access tables to control privileged access for unprivileged users plus the if-then-else trees to figure out and mitigate the bugs introduced caused privilege escalations to have bugs letting unprivileged users have access to privileged operations by escalating their privileges. The subject has now been escalated to QA using AI to generate new if-then-else trees, more crud and an additional level of access tables.
Clearly, the developers of Control Panel git it right, probably because they were thinking about the problem they were solving: setting time and date around the world, not simply porting code without that level of engagement.
Personally, comparing the Settings App to Control Panel, it obvious that the designers of Control Panel had a better appreciation of UI/UX than the designers of Settings app….
You can see this for yourself by making the Settings Apps app less than full screen. Now try to find the related link to the old control panel "Programs and Settings". Its not there? Really? Just make the window full-screen and it will re-appear on the upper right... Its as if the people who designed the new Settings Apps app never have to use it.
When those developers get to hell, their standing desks will be 2m high, their swivel chairs won't stop spinning, their keyboards will have spikes on the keys, their mice will be red-hot, and each mouse click will move the pointer a random distance in a random direction.
Clearly, the developers of Control Panel git it right, probably because
The developers of Control Panel were working on Win 2 or 3, they weren't considering admin permissions.
And on WinXP, you couldn't even see the calendar from the task bar. You needed admin to change the date. It's just that even on WinXP, a lot of users will still logged in that way.
This post has been deleted by its author
I haven't been able to change the timezone in the settings app on my corporate Win10 laptop for several years - the trusty old Control Panel, however, does the job.
I always thought that this is a feature rather than a bug - a periodic reminder to never, ever, ever, ever use the pile of shite that MS calls the Settings app.
This post has been deleted by its author
Looks pretty, but doesn't work.
Not so sure about that.
A priori any generation should have received about the same amount of attention from the wielder of the ugly stick. Although incompetent tattooist (including do-it-on-yourself artists) might have augmented Mr Ugly Stick's efforts.
This post has been deleted by its author
It insists I am on GMT even in the summer.
And it puts this in its meeting invitations.
I was always tempted to turn up an hour late for meetings in the summer and point out that the meeting said, say, 10:00 GMT, which is 11:00 local time and suggest that it be reported as a bug.
Never did, though....
Sadly not all the time. For a good while, not sure if it's still the case, Outlook and its mobile companion products used the timezone desciption in an invite, rather than timezone rules, leading to calendar entries being off by an hour. Not helpful when you use a non-MS email product.
As a very slight aside, one of my clients has a virtual (Windows) server which whenever it is rebooted, insists that it is an hour later than everything else..
The timezone is correct, it is on a domain and is getting the time from the PDC emulator OK, I can log into it with domain credentials so Kerberos isn’t bothered. The host and all other devices are fine - manually reset the time on it (using the classic CP naturally, as the Settings app is completely greyed out), and it’s all happy.
Until the next patch Tuesday the following month. Every...Fscking....Time!
I’ve given up trying to find the underlaying issue - I’m putting it down to demonic possession!
Check your hypervisor for a setting for BIOS clock being UTC or local time. I assume it is setting the clock on startup, and there is a divide in the IT world between operating systems that store the time in UTC, and the way Microsoft do it.
I believe that is a neutral way of phrasing it.
The setting may not be described this way, and may instead be "Select operating system" with this being one of the settings this parameter changes.
«Under UNIX, the timezone is just a single, simple symbolic link to file create/modify. This is what they can't beat. The raw simplicity underneath.»
Individual users can set their TZ environment variable which leverages the same raw simplicity :)
export TZ=":Australia/Sydney"
or
setenv TZ ":Australia/Sydney"
Thanks Mr Olsen. :)
You didn't need Mr Olsen's work to do this. Try
TZ=AEST-10AEDT,M10.1.0/2,M4.1.5.0/3
(This is a first guess, I may have got it wrong, especially the time that the DST switch happens). This worked before the Olsen timezone database was created, and is STILL the Posix standard for TZ.
woke my windows 11 laptop up, just had the lid closed. Found the time and date were both off. was claiming that it was early morning on the 19th when i was looking at the clock at 11:30 pm on the 18th. Not sure why. went into bios and clock and date had been changed to reflect the window time and date. rebooted and was still incorrect. checked to make sure it was communicating with a time server, and that appeared to be ok as was the time zone setting. Had a good internet connection also. Seems to be ok now, but i left it sleeping last night and will check it tonight when i get home from work around 8 pm.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
