Closed jslaybaugh closed 4 years ago
The values returned from properties of a TimeZoneInfo
object are coming from .NET itself, not from TimeZoneConverter.
On non-Windows systems, those values come from ICU when available, and fall back to offsets when not. You can parse through the source code here to understand the details.
On Windows, those value come from NLS data in the registry - up until .NET 5 which is switching to ICU across the board.
You might also be interested in my companion library - TimeZoneNames
Thanks, I'll definitely check out that library for the names -- it'll save me a bunch of lines of code in doing that myself.
But I'm still unclear on how two (seemingly) identical non-windows systems would return different values?
Sorry for the delayed response. Is it possible this is the solution: https://github.com/dotnet/core/issues/2186#issuecomment-472559583 ?
Using:
Problem
Our application is running on linux containers in an Azure Kubernetes cluster. I have 5 pods in a single deployment in the kubernetes cluster and different pods are returning different values for
TimeZoneInfo.StandardName
andTimeZoneInfo.DaylightName
on some pods from other pods in spite of the pods being identical images running identical code on identical configs. When I bash into the pods and runapt list
they both show to havetzdata
installed and show the same information for each:I created a page to reproduce this that you can hit at https://brushfire.com/test/timezones. The first several lines are the machine name and the OS version and culture. Then it lists all the timezones in the following format:
As you can see from the following screenshots, on one pod I'm getting different values from another pod. All my code for returning this list and for my creation of the abbreviation is included below, but fundamentally the issue stems from
TimeZoneInfo.StandardName
andTimeZoneInfo.DaylightName
returning different values on different pods. Any idea why this may be happening?TestController.cs
LocalizationUtility.cs
Extensions.cs