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

Tim Parenti tim at timtimeonline.com
Tue Apr 13 21:01:00 UTC 2021

On Tue, 13 Apr 2021 at 15:36, Paul Eggert via tz <tz at iana.org> wrote:

> On 4/13/21 6:54 AM, Michael[tm] Smith via tz wrote:
> > In the time zone taxonomy, if the term for “Europe/Berlin” is clearly
> “time zone”,
> The theory.html file consistently uses the word "timezone" for that

More specifically, "Europe/Berlin" is really most fundamentally and
correctly called a "timezone identifier", as discussed in theory.html,
often shortened to "TZ identifier" or sometimes "TZID".  It is not a "zone"
or "region" unto itself, nor does it necessarily represent somehow a
particular city, region, or country in its entirety, as political
boundaries shift.

CLDR's notion of a "metazone" — while arguably not the best name — does
more closely align with the general public's notion of a "time zone" as a
(more or less) contiguous, albeit often irregular, band from pole to pole,
or at least stretching roughly north-to-south within a larger region of
interest (typically a continent).  For example, if a typical layperson
asked me whether Orlando and Ottawa are in the same time zone, I would say
yes, as that reflects a broadly-shared cultural notion of "Eastern Time" in
North America, despite the facts that (a) one is America/New_York and one
is America/Toronto, and (b) "Eastern Time" technically means different
things at different times of year.

CLDR's approach isn't perfect, though.  If the question were instead about
Alice Springs and Adelaide, or about Tijuana and Tuscon, those are usually
best described to laypersons as "technically [yes|no], but sometimes…"
situations.  CLDR instead appears to treat these as entirely separate
"metazones" — a reasonable technical choice, but far from the only one that
could be made.

Prior to Indiana's introduction of DST in 2006, while some national
businesses headquartered in, say, Indianapolis correctly published things
like "we are on EST, which is one hour behind New York in the summer", just
as many said things like "we're on Eastern Time in the winter and on
Central Time in the summer", because that phrasing and mental modelling was
considered more useful to a broad US audience that can reasonably be
expected to know a little about the four main time zones in the contiguous
48 states, but not about the technical minutiae of some other state's law
or its implementation.  Situations like Arizona's own "metazone" choose to
ignore any logical contiguity with aligned regions simply because those
regions happen to change over the course of a year.  It is certainly
correct (in a legal sense) to say "Phoenix is on Mountain Standard Time,
always, and that's Its Own Thing", but it can often be just as correct (in
a useful sense) to say "Phoenix happens to be on Pacific Time like Los
Angeles right now, and it will be on Mountain Time like Denver later".

All of this is to say that "metazones" aren't perfect because, really,
nothing can be.  Trying to group together "like TZIDs" in the way you
describe and CLDR attempts really depends on what exactly you're after: If
querying Europe/Berlin now gets you "Central European Time", are you
storing that somewhere? What if that should happen to change later on?  The
proper answers may differ from application to application, and I believe
this complexity contributes greatly to why this project hasn't really taken
that up in the past.

Additionally, we've seen many reports of individual jurisdictions recently
considering changes to their clocks with varying degrees of coordination
with their neighbors.  This ought to remind us to exercise some care and
caution with "metazones" and the like, as the very notion of them relies on
a measure of contiguity and coordination that, while generally in
everyone's best interest to reduce confusion, has never been inherently

Tim Parenti
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20210413/583f0345/attachment.htm>

More information about the tz mailing list