Since you've referenced CLDR already, I may be saying things you know, and you're looking for an "official position" from IANA folks. If so, please feel free to ignore the info below, I'm mostly just a lurker here who has been straddling a few different libraries for Android for a few years, so I appreciate some of the terminology / disconnects. Below I'll refer to identifiers like "Europe/London" as the zone ID. I think the TZDB nomenclature uses "zone name" for this, but I tend to avoid it because it's confusing in the Java / ICU world when also talking about "display names". Somebody who knows better will be along to correct me, but I think strings like 'Central European Summer Time' are obtained in CLDR / ICU internals via the "metazone" mapping, which CLDR originates. i.e. zone IDs that share the same "Central European Summer Time" string at a given point in time are in the same metazone at that time. Zone IDs that have the same offset + rules according to TZDB, even in the same country, may have different metazones because the populace may choose to call their time something different even if they follow the same rules right now. Across borders, two neighboring countries that share the same rules may also choose to observe the same naming (e.g. the EU may like Central European Time) or different (e.g. "Irish Standard Time" / "British Summer Time"). Because names have geopolitical implications, this can get a bit complicated (e.g. Crimea), which is why I'm glad CLDR looks after it. CLDR also specifies times when a zone ID is in a metazone, so a given zone ID that may be in one metazone today may be in a different metazone tomorrow (e.g. Yukon changes last year, IIRC). Metazone assignments often change to track TZDB changes, which can be seen if you look at the history for metazones.xml in Android ( https://cs.android.com/android/platform/superproject/+/master:external/cldr/... ) All that said, metazones could perhaps be ignored as an implementation detail used to derive a name for a zone ID. I tend to refer to names like 'Central European Summer Time' as the (long) "display name". This is because I first encountered these via ICU and Java APIs which use the TimeZone getDisplayName method to obtain them and have constants for long ("Mountain Daylight Time") / short ("MDT") / generic long ("Mountain Time"), etc. Hope that helps, Neil. On Tue, 13 Apr 2021 at 14:55, Michael[tm] Smith via tz <tz@iana.org> wrote:
In the time zone taxonomy, if the term for “Europe/Berlin” is clearly “time zone”, and “GMT+2” is precisely a “timezone offset”, is there a term (other than “time zone”) for what “Central European Summer Time” is — either an authoritative/ normative term, or else at least a best-practice term that’s commonly used?
The context is, I’m updating some of the MDN documentation related to JavaScript methods and properties for dealing with dates, including these articles:
* https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/I... * https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/I...
And in particular, I’m working on trying to describe the timeZoneName property, in the context of the following behavior: Consider the following code:
TZ=Europe/Berlin node -e "console.log(new Intl.DateTimeFormat('en-us', \ { timeZoneName: 'short' }).formatToParts())"
When you run that, what you get back is this:
[ { type: 'month', value: '4' }, { type: 'literal', value: '/' }, { type: 'day', value: '13' }, { type: 'literal', value: '/' }, { type: 'year', value: '2021' }, { type: 'literal', value: ', ' }, { type: 'timeZoneName', value: 'GMT+2' } ]
So part of what I want to explain in the MDN articles is: When you specify “timeZoneName: 'short'”, what you get back as the value for the 'timeZoneName' field in the output is actually a time zone *offset* — not a time zone.
But along with that, I need to deal with describing this case:
TZ=Europe/Berlin node -e "console.log(new Intl.DateTimeFormat('en-us', { timeZoneName: 'long' }).formatToParts())"
When you run that, what you get back is this:
[ { type: 'month', value: '4' }, { type: 'literal', value: '/' }, { type: 'day', value: '13' }, { type: 'literal', value: '/' }, { type: 'year', value: '2021' }, { type: 'literal', value: ', ' }, { type: 'timeZoneName', value: 'Central European Summer Time' } ]
That’s the particular thing I’m struggling with — that is, when you specify “timeZoneName: 'long'”, what do I call the 'Central European Summer Time' that you get back in the output?
Something like “a localized long name for the associated time zone offset” is the best I’ve been able to come up with. But I’ve been hoping there might be some authoritative term for it that I’ve not managed to find yet.
And I realize there’s no “Central European Summer Time” in the zoneinfo data itself — and so implementations get that by doing some kind of lookup against (I guess) CLDR. So I guess it’s expected that the documentation for the IANA timezone database itself doesn’t have a term for it.
And I guess it’s also unsurprising that CLDR seems to just use the term “time zone” to refer to it — since CLDR doesn’t need to bee more precise and since because CLDR doesn’t need to do anything with the actual canonical time zone names such as Europe/Berlin, it doesn’t have the problem of distinguishing between what a time zone is and what time zone offset is.
But from what I’ve seen in issues and questions reported by developers at MDN and Stack Overflow, probably the single biggest source of chronic frustration that developers have when dealing with date-related methods and properties in programming languages comes down to a fundamental misunderstanding of what a time zone is, and how it differs from time zone offset.
So I’ve admired what Matt Johnson-Pint has done at Stack Overflow in answering many questions — and in putting the https://stackoverflow.com/tags/timezone/info and https://stackoverflow.com/tags/timezone-offset/info pages together — to provide developers with the kind of clarity they need to solve their problems.
And so what I’m hoping to do with my MDN changes is to bring similar clarity to developers through MDN.
And so also that’s why it seems important to get the terminology right at MDN when explaining to developers exactly what “Central European Summer Time” is.
–Mike
-- Michael[tm] Smith https://people.w3.org/mike
-- Google UK Limited Registered Office: 6 Pancras Square, London, N1C 4AG Registered in England Number: 3977902