Setting TimeZone for a Windows Container

Question

I am trying to set the timezone of a WindowsContainer which is based on the windows nano server 2019 Build 1809.

One of the simplest way of doing it for linux containers is to set the TimeZone environment variable as shown below:

docker run -e TZ=Asia/Kolkata ubuntu date

Do we have anything similar for Windows Containers. Based on general windows approach i am trying to set it in the entrypoint script using PowerShell like (as shown below) but it is also giving me an error.

Set-TimeZone -Name "India Standard Time"
Set-TimeZone : Access is denied
At line:1 char:1
+ Set-TimeZone -Name "India Standard Time"
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : FromStdErr: (:) [Set-TimeZone], Win32Exception
+ FullyQualifiedErrorId : SetTimeZoneFailed,Microsoft.PowerShell.Commands.SetTimeZoneCommand

Any idea on how this can be done for Windows Containers based on Windows Nanoserver 2019 Build 1809?

Aboveground

Is your host set to non-English? (if so, github.com/moby/moby/issues/38146 might be related!) – Fidelia

Thanks @Fidelia , what I found out that in case of Windows Container they are able to synchronize with the Host and the corresponding Time zone is set to that of the Host OS. For now this functionally works for me..... so i am all Good – Aboveground

@SoumenMukherjee Would you mind making your comment an answer? I think it should be. At least it worked for me the same way. – Lindie

I don't this works in all the cases. if the hosts are cloud managed (ex: AWS ECS) I couldn't find any way to change Host TimeZone – Wynne

I think this is how you should do it..docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/… – Aboveground

Answer 1

Tzutil.exe and PowerShell's Set-TimeZone as well as all apps changing the timezone through the system APIs will be able to set the timezone from within containers in --isolation=process mode starting from Windows Server 2022. Whatever works on the host will work inside containers, including DST even if the container's timezone has a different DST policy than the host, for example some regions enter/exit DST at a different date, or not at all.

Initially, new and existing containers will inherit the host's timezone (the timezone bias and all other timezone settings, such as the DST policy) as previously, but once set from within a particular container instance, the container in question will stick to it for the rest of its lifetime, ever across reboots, until changed again.

Changing the timezone within a particular container instance has no side effect on other containers, and of course no side effect on the host and vice-versa.

Brigidbrigida

Answer 2

Edited: as Pierre-Luc Champigny pointed, according to Microsoft, this is now supported on ltsc versions and upcoming ones: https://learn.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/virtual-time-zone

There is no way to properly set globalization settings like Time Zone, Language, or Windows-Location on Windows Server Core containers.

• tzutil throws lack of privileges error
• registry settings are ignored when container starts

It seems like you have to ensure the correct Time Zone on container host. That's doesn't make much sense, AFAIK, the whole thing about containers is ship it as image once and run it everywhere, with environment isolation and integrity.. right?!

Anyway you can see more detail on that issue on github.

Also, I've open this suggestion on Windows Server uservoice, to change that behavior.

Also, I've open this feature suggestion for improving Azure AKS host configuration for Time Zone.

Milan

I will add to the voice :-) – Aboveground

...the team is aware of the issue :-) What happens at this time (10/2020) is the time zone is not virtualized and whatever is set on the host bleeds into containers created with --isolation=process – Brigidbrigida

Your answer is exactly correct, although this will change with Windows Server 2022. – Brigidbrigida

@Joao can you update your answer? According to Microsoft, this is now supported on ltsc versions and upcoming ones: learn.microsoft.com/en-us/virtualization/windowscontainers/… – Dumps

Answer 3

As of May 2021 in the 2105B servicing release (WS2019 build 10.0.17763.1935) the ability to configure the time zone within a container is now supported. You can use either tzutil or Set-TimeZone to set a time zone configuration local to the container.

More info is available here: https://learn.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/virtual-time-zone

Antione

It's worth mentioning, that both the host and container need this patch: "you need both host and guest versions containing this feature, which means running on a 2105B servicing patch or higher" – Cord

Answer 4

Did you try to use the tzutil command?

• Method 1:

  Following an example to use the command and set an Australian time zone:

  tzutil /s "AUS Eastern Standard Time"
  

• Method 2:

  The registry entry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation has all the information relating to timezone.

  From a virtual or physical machine with the correct time zone, you can export the registry values and import to the container.

Betteann

Setting the timezone is blocked from within containers in --isolation=process mode as I write this. The reason is the timezone code in the kernel is not virtualized but will soon be, starting from Windows Server 2022 as recently announced at MS Ignite 2021. Currently, changing the timezone from within a container would bleed to the host and other containers, which is undesirable. Containers also don't read that registry location, this data is read only during kernel initialization and containers in --isolation=process mode share the host's kernel, which is obviously already initialized. – Brigidbrigida

Answer 5

What I found out that in case of Windows Container they are able to synchronize with the Host and the corresponding Time zone is set to that of the Host OS , so we do not really need to do anything specific to set the TimeZone of the docker container.

Aboveground