To Reproduce Steps to reproduce the behavior:

1. Deploy RHOSO18 with UTC timezone on OCP and EDPM nodes
2. Launch a Windows instance with local timezone, e.g. Asia/Tokyo(UTC+9:00).
3. The time in Windows instance shows -9:00 from the current actual local time until NTP is synced.

Expected behavior

• Windows instance records the proper local time from boot.

Bug impact

• All windows instances with local timezone hits this issue.

Known workaround

• Possible Workaround A: Configure EDPM node with local timezone.
  But this method is not tested with our QE and may have an impact the future update. Also, mixed timezone environment increases the difficulty in troubleshooting.
• Possible Workaround B: Configure Windows's RTC is recognized as UTC.
  While I cannot find the official source in Microsoft, it seems to be the way to set UTC to Windows' RTC.
  Add 'RealTimeIsUniversal' and set to 0x1.

Additional context

• This issue didn't problem in RHOSP releases when TimeZone T-H-T parameter was not UTC.

In nova, if os_type='windows' is passed. it tries to set offset as localtime[1]
https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L6578-L6592

It works well if hypervisor timezone is configured to local time.
However, when hypervisor is configured as UTC timezone, 'localtime' offset is UTC.
Also, it strongly assumes that running Windows instances uses the same timezone on the hypervisor.

In libvirt side, we have an interface to set the specific timezone for guest clock, https://libvirt.org/formatdomain.html#time-keeping
nova has the parameter to set timezone for libvirt option, https://github.com/openstack/nova/blob/master/nova/virt/libvirt/config.py#L780-L806

The ideal way to fix this issue seems to pass timezone for instance from flavor/image as extra_spec then nova reads it and configure libvirt properly.