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/Intl/DateTimeFormat/DateTimeFormat
* https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat/formatToParts

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