[tz] Terminology: “Central European Summer Time” vs “Europe/Berlin”

Neil Fuller nfuller at google.com
Tue Apr 13 14:26:14 UTC 2021


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/common/supplemental/metaZones.xml;l=1;bpv=1
)

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 at 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/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
>


-- 
Google UK Limited

Registered Office: 6 Pancras Square, London, N1C 4AG
Registered in England Number: 3977902
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20210413/667f60e3/attachment.html>


More information about the tz mailing list