Terminology: “Central European Summer Time” vs “Europe/Berlin”
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
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
On Apr 13, 2021, at 7:26 AM, Neil Fuller via tz <tz@iana.org> wrote:
All that said, metazones could perhaps be ignored as an implementation detail used to derive a name for a zone ID.
Perhaps the tzdb *should* maintain a notion of "metazones", giving them names; it would leave it up to the CLDR to assign localized abbreviations and display names for them.
Perhaps the tzdb *should* maintain a notion of "metazones", giving them names; it would leave it up to the CLDR to assign localized abbreviations and display names for them.
If TZDB has the information to do this, and it doesn't open the TZDB maintainers up to more geopolitical headaches than today, I personally think that's a good idea. I'm assuming it would actually be usable for downstream folks. Somebody on the CLDR side may come along later and point out where the art lies in all this and why TZDB may want to steer clear. They've been tracking TZDB updates for years so they have probably encountered any issues along the way. One disconnect I'm aware of, in the past (at least) CLDR liked to have identifier stability. As I understand it, they have declared their zone IDs as "stable" (canonical, I think, in their nomenclature). Although I think TZDB already gives guarantees about never removing IDs, CLDR commit to not changing the ones they use. Although they recognize all TZDB's zone IDs, adding new ones as needed, they still use ones like Asia/Calcutta internally as their keys in preference to Asia/Kolkata. If there were an appetite for TZDB to start mastering metazones, they might find guarantees useful around metazone IDs not shifting over time so they wouldn't need to build in indirection. As a side note, I was also present at some recent discussions where, for embedded usage, ICU folks were considering "short" IDs for some time zone concepts. I confess I don't remember / didn't catch the details, but it was something to do with some low level Rust types and I think the concern that the TZDB IDs are quite long and not that friendly for IoT devices. It's well off topic for this thread, but I thought I'd mention in case there is any appetite for TZDB to become the authority for that too, i.e. perhaps it could also master a new set of aliases for zone IDs with length / stability guarantees. This is highly speculative on my part. Neil. On Tue, 13 Apr 2021 at 19:52, Guy Harris <gharris@sonic.net> wrote:
On Apr 13, 2021, at 7:26 AM, Neil Fuller via tz <tz@iana.org> wrote:
All that said, metazones could perhaps be ignored as an implementation detail used to derive a name for a zone ID.
Perhaps the tzdb *should* maintain a notion of "metazones", giving them names; it would leave it up to the CLDR to assign localized abbreviations and display names for them.
-- Google UK Limited Registered Office: 6 Pancras Square, London, N1C 4AG Registered in England Number: 3977902
On Apr 13, 2021, at 12:36 PM, Neil Fuller <nfuller@google.com> wrote:
As a side note, I was also present at some recent discussions where, for embedded usage, ICU folks were considering "short" IDs for some time zone concepts. I confess I don't remember / didn't catch the details, but it was something to do with some low level Rust types and I think the concern that the TZDB IDs are quite long and not that friendly for IoT devices.
They're also not that friendly for people trying to avoid political arguments and complaints that "there's no TZDB ID with my important city's name in it". :-) But, yes, this is a topic for a different thread.
On 4/13/21 11:52 AM, Guy Harris via tz wrote:
Perhaps the tzdb*should* maintain a notion of "metazones", giving them names; it would leave it up to the CLDR to assign localized abbreviations and display names for them.
We could maintain an English-language table mapping time zone abbreviations to time zone display names, e.g.: CEST Central European Summer Time CET Central European Time CST Central Standard Time CST China Standard Time ... Unfortunately, resolving ambiguities (as in CST above) would be needed if such a table is to be useful, and this would require something more complicated and messy. Not sure it's worth the effort if CLDR already has a solution for this.
On Apr 13, 2021, at 6:54 AM, Michael[tm] Smith via tz <tz@iana.org> wrote:
In the time zone taxonomy, if the term for “Europe/Berlin” is clearly “time zone”,
Perhaps that's what's currently used, but I'm not convinced it *should* be used. I tend to refer to them as "tzdb regions", as they don't correspond to what I suspect most people think of as "time zones". A tzdb region may well be in different "time zones" in the sense of a given standard time offset from UTC (I think there are examples of that in the tzdb), and there may be more than one tzdb region with the same standard time offset from UTC, so they're in the same "time zone", but with different DST rules or with different histories of DST rules (for example, in the US some regions within a given "time zone" may not do DST while other regions within the same "time zone" do).
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?
"Central European Summer Time" isn't a "time zone", either. I have the impression that "Central European Time" is what the general public would cal a "time zone"; "Central European Summer Time" is "time, in the Central European Time zone, when summer time is in effect"; I'm not sure whether there's an English-language term used by the general public for items such as "Central European Summer Time", and don't know whether any other languages have a term for it.
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, distinguishing between "timezone" and "time zone" as follows: "Each timezone typically corresponds to a geographical region that is smaller than a traditional time zone, because clocks in a timezone all agree after 1970 whereas a traditional time zone merely specifies current standard time." As I vaguely recall, this was after some discussion of alternative terms for the notion, terms like "tzdb regions". All the terms had problems (obviously "timezone" has the problem of being too close to "time zone"), but "timezone" won the day at the time. I believe part of the reason for avoiding the word "region" was to bypass political issues of control of geographical regions. In theory.html, strings like "CEST" are called "time zone abbreviations". There is no term in theory.html for phrases like "Central European Summer Time" as these phrases are not in tzdb. I suppose we could call them "time zone display names" or something like that.
On Tue, 13 Apr 2021 at 15:36, Paul Eggert via tz <tz@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 guaranteed. -- Tim Parenti
On 2021-04-13 21:01, Tim Parenti via tz wrote:
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".
Well, "timezone identifier" occurs in titles, but the text in theory.html says "Each timezone has a name that uniquely identifies the timezone." and the text usually says "timezone name". Michael Deckers.
On 4/13/21 2:01 PM, Tim Parenti wrote:
Additionally, we've seen many reports of individual jurisdictions recently considering changes to their clocks with varying degrees of coordination with their neighbors.
Yes, and there's large source of potential confusion here in real-world applications. For example, the Sunshine Protection Act of 2021 proposed by Senators Rubio et al. would redefine "Pacific Standard Time" to mean 7 hours behind UTC, "Mountain Standard Time" to mean 6 hours behind UTC, etc. If it passes, most of Arizona will stop observing the old MST (-07) and I expect it will start observing the new PST (-07). The proposed law also seems to require the Navajo Nation, which currently observes the old MST/MDT (-07/-06), to switch to the new MST (-06). If this happens, nomenclature issues will abound. For example, we could see this behavior in the GNU/Linux shell: $ TZ=America/Los_Angeles date -d 2021-01-01 +"%Y-%m-%d %H:%M %z (%Z)" 2021-01-01 00:00 -0800 (PST) $ TZ=America/Los_Angeles date -d 2022-01-01 +"%Y-%m-%d %H:%M %z (%Z)" 2022-01-01 00:00 -0700 (PST) $ TZ=America/Phoenix date -d 2021-01-01 +"%Y-%m-%d %H:%M %z (%Z)" 2021-01-01 00:00 -0700 (MST) $ TZ=America/Phoenix date -d 2022-01-01 +"%Y-%m-%d %H:%M %z (%Z)" 2022-01-01 00:00 -0700 (PST) Any software that thinks that "PST" means "8 hours behind UTC" will be broken. As will any software that thinks that "PST" means "7 hours behind UTC", for older timestamps. Admittedly such software is dicey anyway, but it's out there and it's in widespread use. This very email is being sent using the format of Internet RFC 5322, which defines "PST" to be equivalent to "-0800". (Luckily it says "PST" is obsolescent, but still....) The situations for time zone abbreviations in Europe, the UK, Ireland, etc. will be even more complicated if they go through with plans to institute permanent DST or permanent standard time or whatever it is they might do. It surely will be an even bigger mess to name and abbreviate the resulting time zones. To avoid the resulting fallout, perhaps we should remove all alphabetic time zone abbreviations from tzdb, other than "UTC" and the "xMT" abbreviations which are pretty much immune to this sort of thing and which we need for other reasons. Or at least we should perhaps remove alphabetic abbreviations for zones going through upheaval, as any such abbreviations are likely to confuse people.
participants (6)
-
Guy Harris -
Michael H Deckers -
Michael[tm] Smith -
Neil Fuller -
Paul Eggert -
Tim Parenti