class NodaTime.​TimeZones.​TzdbDateTimeZoneSource

Remarks The group of values for a key never contains the canonical ID, only aliases. Any time zone ID which is itself an alias or has no aliases linking to it will not be present in the lookup. The aliases within a group are returned in alphabetical (ordinal) order.

Remarks <para>This map contains an entry for every ID returned by <see cref="M:NodaTime.TimeZones.TzdbDateTimeZoneSource.GetIds" />, where canonical IDs map to themselves.</para> <para>The returned map is read-only; any attempts to call a mutating method will throw <see cref="T:System.NotSupportedException" />.</para>

Remarks Every zone location's time zone ID is guaranteed to be valid within this source (assuming the source has been validated).

Remarks <p> This location data differs from <see cref="P:NodaTime.TimeZones.TzdbDateTimeZoneSource.ZoneLocations" /> in two important respects: <ul><li>Where multiple similar zones exist but only differ in transitions before 1970, this location data chooses one zone to be the canonical "post 1970" zone. </li><li> This location data can represent multiple ISO-3166 country codes in a single entry. For example, the entry corresponding to "Europe/London" includes country codes GB, GG, JE and IM (Britain, Guernsey, Jersey and the Isle of Man, respectively). </li></ul></p> <p> Every zone location's time zone ID is guaranteed to be valid within this source (assuming the source has been validated). </p>

Remarks <para> This source returns a string such as "TZDB: 2013b (mapping: 8274)" corresponding to the versions of the tz database and the CLDR Windows zones mapping file. </para> <para> Note that there is no need to parse this string to extract any of the above information, as it is available directly from the <see cref="P:NodaTime.TimeZones.TzdbDateTimeZoneSource.TzdbVersion" /> and <see cref="P:NodaTime.TimeZones.Cldr.WindowsZones.Version" /> properties. </para>

Remarks <para> Where a TZDB alias isn't present directly in the Windows mapping, but its canonical ID is, the dictionary will contain an entry for the alias as well. For example, the TZDB ID "Africa/Asmara" is an alias for "Africa/Nairobi", which has a Windows ID of "E. Africa Standard Time". "Africa/Asmara" doesn't appear in the Windows mapping directly, but it will still be present in the returned dictionary. </para> <para> Where a TZDB canonical ID isn't present in the Windows mapping, but an alias is, the dictionary will contain an entry for the canonical ID as well. For example, the Windows mapping uses the TZDB ID "Asia/Calcutta" for "India Standard Time". This is an alias for "Asia/Kolkata" in TZDB, so the returned dictionary will have an entry mapping "Asia/Kolkata" to "Asia/Calcutta". If multiple aliases for the same canonical ID have entries in the Windows mapping with different Windows IDs, the alias that is earliest in lexicographical ordering determines the value for the entry. </para> <para> If a canonical ID is not present in the mapping, nor any of its aliases, it will not be present in the returned dictionary. </para>

Remarks Sometimes the Windows mapping contains values which are not canonical TZDB IDs. Every value in the returned dictionary is a canonical ID. For example, the Windows mapping contains as "Asia/Calcutta" for the Windows ID "India Standard Time", but "Asia/Calcutta" is an alias for "Asia/Kolkata". The entry for "India Standard Time" in the returned dictionary therefore has "Asia/Kolkata" as the value.