I always wondered why setting time zones was so hard.  Shouldn’t devices be able to figure this out themselves?  For devices like cell phones, this is pretty simple (now at least, since we have digital cell phone services rather than analog ones) as this can be provided directly by the cell network provider (although be prepared to be frustrated if you live near a time zone boundary, as the time will flip based on the cell tower your phone connects to).  And maybe it’s not too bad for devices that have GPS capabilities, since they can get a time zone based on a location.  But of course most PCs don’t have either of these – no cell modems and no GPS.

Windows does try to set the time zone based on the location of the device, but without a GPS that location is based more on heuristics, e.g. the IP address on the internet being used.  Try it out using your favorite search engine with a query like “where am I” and it will use that sort of mechanism.  There are multiple pieces needed to make that work, including Location Services (needs to be enabled) and the TZAUTOUPDATE service (enabled for you when you choose the “Automatically update time zone” option in Settings).  But I still struggle to make it work, especially during OOBE while you are provisioning a new device.

So what does work?  Well, you can set the time zone manually, which is really easy to do via PowerShell:

Set-TimeZone -Id “Eastern Standard Time”

And a sample of that is included in the Autopilot Branding package that I published to GitHub.  That works well if you have one time zone to worry about, but isn’t particularly flexible if you have to worry about multiple.  A few people have built scripts to tie in their own location services (see the comments in this blog for examples), setting the time zone using the location result, so it is possible, just requires a little bit of extra work.

The next possibility is via a new MDM policy added in Windows 10 1903.  That’s not exposed through Intune yet, but at least you can set it up via a custom OMA-URI.  Create a “Custom” device configuration policy and add a setting to it:

• Name:  Anything you want
• Description:  Anything you want
• OMA-URI:  ./Vendor/MSFT/Policy/Config/TimeLanguageSettings/ConfigureTimeZone
• Data type:  String
• Value:  Any of the ID strings returned by the PowerShell “Get-TimeZone -ListAvailable” command

But the challenge is then targeting a policy to an appropriate group of machines – pretty simple if you only have to worry about one time zone, but rather messy when you have to worry about several.  How do you build those Azure AD groups?

There is another possibility too:  Setting the time zone via DHCP.  That process is described via RFC 4833, and it seems like that would be a decent option – if Windows actually implemented that client-side.  More on that in part 2…