Class WindowsZones
<windowsZones>
element of CLDR supplemental data.
Inheritance
Inherited Members
Namespace: NodaTime.TimeZones.Cldr
Assembly: NodaTime.dll
Syntax
public sealed class WindowsZones
Remarks
Properties
MapZones
Declaration
public IList<MapZone> MapZones { get; }
Property Value
Type | Description |
---|---|
IList<MapZone> |
Remarks
Each mapping consists of a single Windows time zone ID and a single territory to potentially multiple TZDB IDs that are broadly equivalent to that Windows zone/territory pair.
Mappings for a single Windows system time zone can appear multiple times in this list, in different territories. For example, "Central Standard Time" maps to different TZDB zones in different countries (the US, Canada, Mexico) and even within a single territory there can be multiple zones. Every Windows system time zone covered within this collection has a "primary" entry with a territory code of "001" (which is the value of PrimaryTerritory) and a single corresponding TZDB zone.
This collection is not guaranteed to cover every Windows time zone. Some zones may be unmappable (such as "Mid-Atlantic Standard Time") and there can be a delay between a new Windows time zone being introduced and it appearing in CLDR, ready to be used by Noda Time. (There's also bound to be a delay between it appearing in CLDR and being used in your production system.) In practice however, you're unlikely to wish to use a time zone which isn't covered here.
If the data is loaded from the legacy resource format, this will only include the primary mappings.
PrimaryMapping
Declaration
public IDictionary<string, string> PrimaryMapping { get; }
Property Value
Type | Description |
---|---|
IDictionary<String, String> |
TzdbVersion
Declaration
public string TzdbVersion { get; }
Property Value
Type | Description |
---|---|
String |
Remarks
The CLDR mapping file usually lags behind the TZDB file somewhat - partly because the
mappings themselves don't always change when the time zone data does. For example, it's entirely
reasonable for a TzdbDateTimeZoneSource with a TzdbVersion of
"2013b" to be supply a WindowsZones
object with a TzdbVersion
of "2012f".
This property will never return a null value, but will be "Unknown" if the data is loaded from the legacy resource format.
Version
Declaration
public string Version { get; }
Property Value
Type | Description |
---|---|
String |
Remarks
As with other IDs, this should largely be treated as an opaque string, but the current method for
generating this from the mapping file extracts a number from an element such as <version number="$Revision: 7825 $"/>
.
This is a Subversion revision number, but that association should only be used for diagnostic curiosity, and never
assumed in code.
This property will never return a null value.
WindowsVersion
Declaration
public string WindowsVersion { get; }
Property Value
Type | Description |
---|---|
String |
Remarks
At the time of this writing, this is populated (by CLDR) from the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\TzVersion, so "7dc0101" for example.
This property will never return a null value, but will be "Unknown" if the data is loaded from the legacy resource format.