-
Notifications
You must be signed in to change notification settings - Fork 256
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Set default time zone for WCOW UVM #1192
Conversation
ef3ad3a
to
570cb77
Compare
Gonna draft again until I can get something answered |
internal/uvm/timezone.go
Outdated
StandardName: "GMT Standard Time", | ||
StandardBias: 0, | ||
DaylightName: "GMT Daylight Time", | ||
DaylightBias: -60, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You mentioned also finding info on a "UTC" time zone. Did that one have DST? I would rather we use something that doesn't have DST if we can find a good standard.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It does not iirc, I'm working to swap it over and rebase this PR right now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, using UTC now instead.
e441028
to
c672838
Compare
I've sinned and force pushed, but to be fair this is the first time it's been out of draft for review 😝 |
For the v2 hcs code paths it seems the only time a time zone is set is if a new field on the guest connection settings is present (which we don't have) while using the internal guest connection (shim -> hcs -> gcs). Otherwise the guest is just left without a time zone set, so things like tzutil or the get-timezone powershell cmdlet will return an invalid time zone set. We swapped to always using the external guest connection we maintain in the shim so we need to set a time zone explicitly. This change issues a request to the gcs to set a timezone via the same method that hcs uses internally. It sets the guests time zone to whatever is present on the host which is the docker behavior, and then all containers in the vm should inherit this. Additionally expose an option to override this behavior and just set the time zone to GMT. If the container wants to change its timezone to something else, it is free to on supported images. See https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/virtual-time-zone Signed-off-by: Daniel Canter <dcanter@microsoft.com>
c672838
to
78d7419
Compare
Fixing merge conflicts after Amit's chronyd change got in |
lgtm |
For the v2 hcs code paths it seems the only time a time zone is set is if a new field on the guest connection settings is present (which we don't have) while using the internal guest connection (shim -> hcs -> gcs). Otherwise the guest is just left without a time zone set, so things like tzutil or the get-timezone powershell cmdlet will return an invalid time zone set. We swapped to always using the external guest connection we maintain in the shim so we need to set a time zone explicitly. This change issues a request to the gcs to set a timezone via the same method that hcs uses internally. It sets the guests time zone to whatever is present on the host which is the docker behavior, and then all containers in the vm should inherit this. Additionally expose an option to override this behavior and just set the time zone to UTC. If the container wants to change its time zone to something else, it is free to on supported images. See https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/virtual-time-zone Signed-off-by: Daniel Canter <dcanter@microsoft.com>
For the v2 hcs code paths it seems the only time a time zone is set is if
a new field on the guest connection settings is present (which we don't have)
while using the internal guest connection (shim -> hcs -> gcs). Otherwise
the guest is just left without a time zone set, so things like tzutil or
the get-timezone powershell cmdlet will return an invalid time zone set.
We swapped to always using the external guest connection we maintain in the
shim so we need to set a time zone explicitly.
This change issues a request to the gcs to set a timezone via the same method that
hcs uses internally. It sets the guests time zone to whatever is present on
the host which is the docker behavior, and then all containers in the vm
should inherit this. If the container wants to change its timezone it can
do so if it's on a supported sku.
See https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/virtual-time-zone
Signed-off-by: Daniel Canter dcanter@microsoft.com