Re: [tz] Definition of "timezone"
On 2023-12-21 07:08, ApoY2k wrote:
do you (or your peers on the tz project) consider a "timezone" to be inherently tied to the real-world geographical features they are used for, or is the word "timezone" in this context more broader understood as "any 'Zone' entry in the tzdb" - which would e.g. also denote "Etc/UTC" as a "real timezone".
I'll cc this to tz@iana.org to see what others think. There's no formal definition. In TZDB commentary I tend to use "timezone" roughly as a synonym for "TZ setting", that is, for valid values of the TZ environment variable. In that sense there is a huge number of timezones since this includes POSIX TZ strings, and "Europe/London", "Etc/UTC" and "GMT0BST,M3.5.0/1,M10.5.0" all denote timezones. In contrast, the TZDB commentary uses "time zone" for the more common understanding in the real world, that is, the maximal-sized geographical region where clocks currently all have the same reading. In that sense there are 37 time zones right now, though the number changes depending on when you ask the question. The TZDB commentary doesn't use a name for the concept you're asking about, but I suppose "geographical timezone" would do. Admittedly the terminology is not always clear in this area. PS. I got the number "37" as follows: $ tzselect Please identify a location so that time zone rules can be set correctly. Please select a continent, ocean, "coord", "TZ", "time", or "now". 1) Africa 2) Americas 3) Antarctica 4) Arctic Ocean 5) Asia 6) Atlantic Ocean 7) Australia 8) Europe 9) Indian Ocean 10) Pacific Ocean 11) coord - I want to use geographical coordinates. 12) TZ - I want to specify the timezone using the POSIX TZ format. 13) time - I know local time already. 14) now - Like "time", but configure only for timestamps from now on. #? 14 The system says Universal Time is Thu Dec 21 20:00. Assuming that's correct, what is the local time? 1) Thu Dec 21 09:00 14) Thu Dec 21 20:00 27) Fri Dec 22 04:00 2) Thu Dec 21 10:00 15) Thu Dec 21 21:00 28) Fri Dec 22 04:45 3) Thu Dec 21 10:30 16) Thu Dec 21 22:00 29) Fri Dec 22 05:00 4) Thu Dec 21 11:00 17) Thu Dec 21 23:00 30) Fri Dec 22 05:30 5) Thu Dec 21 12:00 18) Thu Dec 21 23:30 31) Fri Dec 22 06:00 6) Thu Dec 21 13:00 19) Fri Dec 22 00:00 32) Fri Dec 22 06:30 7) Thu Dec 21 14:00 20) Fri Dec 22 00:30 33) Fri Dec 22 07:00 8) Thu Dec 21 15:00 21) Fri Dec 22 01:00 34) Fri Dec 22 08:00 9) Thu Dec 21 16:00 22) Fri Dec 22 01:30 35) Fri Dec 22 09:00 10) Thu Dec 21 16:30 23) Fri Dec 22 01:45 36) Fri Dec 22 09:45 11) Thu Dec 21 17:00 24) Fri Dec 22 02:00 37) Fri Dec 22 10:00 12) Thu Dec 21 18:00 25) Fri Dec 22 02:30 13) Thu Dec 21 19:00 26) Fri Dec 22 03:00 #?
On Dec 21, 2023, at 12:01 PM, Paul Eggert via tz <tz@iana.org> wrote:
In TZDB commentary I tend to use "timezone" roughly as a synonym for "TZ setting", that is, for valid values of the TZ environment variable. In that sense there is a huge number of timezones since this includes POSIX TZ strings, and "Europe/London", "Etc/UTC" and "GMT0BST,M3.5.0/1,M10.5.0" all denote timezones.
I've used the term "tzdb region" or "IANA tzdb region" in a similar fashion, although I've only used it to refer to regions defined by the tzdb, not POSIX-style TZ values. I noticed the use of "timezone", and *thought* I'd seen some document explicitly stating that there are "timezones" and there are "time zones" and indicating the difference, and so have switched to "timezone", e.g. in the current Editor's Copy of the Internet-Draft for the pcapng capture file format, to which I added an option for Interface Description Blocks named "if_iana_tzname", containing the tzid for the timezone in which the capture was made, so that programs that process pcapng files (especially ones built in a language and environment that has support for accessing timezones by name, e.g. systems that provide localtime_rz()) can show local times, in the location where the capture was done, for packet timestamps: https://ietf-opsawg-wg.github.io/draft-ietf-opsawg-pcap/draft-ietf-opsawg-pc... However, I checked the Theory document at https://data.iana.org/time-zones/theory.html and it isn't *quite* as explicit as I'd thought: 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. For example, applications that deal with current and future timestamps in the traditional North American mountain time zone can choose from the timezones America/Denver which observes US-style daylight saving time (DST), and America/Phoenix which does not observe DST. Applications that also deal with past timestamps in the mountain time zone can choose from over a dozen timezones, such as America/Boise, America/Edmonton, and America/Hermosillo, each of which currently uses mountain time but differs from other timezones for some timestamps after 1970. Perhaps we should more explicitly state that "timezone" and "time zone" are different names for different things, with a "timezone" *not* corresponding to what most people think of as a "time zone".
The TZDB commentary doesn't use a name for the concept you're asking about, but I suppose "geographical timezone" would do.
Which concept is that? ApoY2k said
do you (or your peers on the tz project) consider a "timezone" to be inherently tied to the real-world geographical features they are used for, or is the word "timezone" in this context more broader understood as "any 'Zone' entry in the tzdb" - which would e.g. also denote "Etc/UTC" as a "real timezone".
Are you referring to the first concept - something that is "inherently tied to the real-world geographical features they are used for" - or the second concept, which sounds like a "timezone"? Is the first concept a subset of timezones, restricted to those timezones that have a geographical definition rather than a more abstract definition such as "everything in UTC" for Etc/UTC?
On 2023-12-21 12:43, Guy Harris wrote:
https://data.iana.org/time-zones/theory.html
and it isn't *quite* as explicit as I'd thought:
Each timezone typically corresponds to a geographical region that is smaller than a traditional time zone ...
Perhaps we should more explicitly state that "timezone" and "time zone" are different names for different things, with a "timezone" *not* corresponding to what most people think of as a "time zone".
I was hoping that the quoted phrase was enough for that, but perhaps not. Perhaps italicize or quote "timezone" and "time zone" in it? Or some other rewording?
The TZDB commentary doesn't use a name for the concept you're asking about, but I suppose "geographical timezone" would do.
Which concept is that? ApoY2k said
do you (or your peers on the tz project) consider a "timezone" to be inherently tied to the real-world geographical features they are used for, or is the word "timezone" in this context more broader understood as "any 'Zone' entry in the tzdb" - which would e.g. also denote "Etc/UTC" as a "real timezone".
Are you referring to the first concept - something that is "inherently tied to the real-world geographical features they are used for" - or the second concept, which sounds like a "timezone"?
The former.
Is the first concept a subset of timezones, restricted to those timezones that have a geographical definition rather than a more abstract definition such as "everything in UTC" for Etc/UTC?
Yes.
On 2023-12-21 07:08, ApoY2k wrote:
do you (or your peers on the tz project) consider a "timezone" to be inherently tied to the real-world geographical features they are used for, or is the word "timezone" in this context more broader understood as "any 'Zone' entry in the tzdb" - which would e.g. also denote "Etc/UTC" as a "real timezone".
</lurk> Yeah I've always carried the nagging feeling that the terminology can be confusing. If you google "time zone map", many of the links you get will display a map like the one here: https://www.timeanddate.com/time/map/ Obviously the time zones depicted on that map and others like it are far more generalized than the time zones that the TZDB defines. The IANA TZDB reflects the geopolitical differences in accounting for the number of hours offset from GMT that a completely arbitrary place has. This place can be an entire country or a lone Antarctic research station; its's always(?) some subset of the large swaths of land depicted on those "standard time zone" maps. Because of this, it has always felt a little strange to me to refer to the TZDB as the "time zone database" because its more detailed contents reflect nothing like the "standard time zone map" depicted at the above URL, and vice versa. Because of those innately human and arbitrary differences, I've always wondered if the TZDB should be thought of more as a "time locale database." This is borrowing a concept from the internationalization and localization (i18n, i10n) systems in computing that exist to address another innately human thing - language. I feel like use of "locale" to describe these entries in the TZDB (TLDB?) better-conveys the local and morphing nature of a given area's sense of time, kind of like how language is thought of, I guess? For example, the standard time zone known as GMT-6 contains central Canada, the central United States, and much of Mexico and Central America. Looking at the above reference map, you might think that all people in this time zone follow the same rules and are always on the same clock. We know that's not the case - the US and most of Canada still observe DST rules which periodically alter this time zone's effective GMT offset in those areas, but some parts of Canada, all of Mexico, and all other counties in that time zone do not observe DST even though they are geographically within the time zone known as GMT-6. I haven't done an exhaustive search, but I don't doubt that there are two or more countries or areas within the same "standard time one" that all observe DST, but at different start and end times. These break that one large GMT-6 time zone - and any standard time zone for that matter - up in to what I think should be referred to as "time locales". I don't know, I'm new around here and am bracing myself for possible incoming fire because of that thought. :D As for UTC, I feel that it being in the database is for convenience. We all know UTC is not a time zone, but rather a time coordinate. It just happens to coincide with GMT, so why not? I maintain an OS *and* have deep involvement in astronomy and astrometry so the whole UTC/GMT/UT1 association here amuses me. It doesn't bother me. /dale
On Dec 21, 2023, at 3:12 PM, Dale Ghent via tz <tz@iana.org> wrote:
Because of those innately human and arbitrary differences, I've always wondered if the TZDB should be thought of more as a "time locale database." This is borrowing a concept from the internationalization and localization (i18n, i10n) systems in computing that exist to address another innately human thing - language. I feel like use of "locale" to describe these entries in the TZDB (TLDB?) better-conveys the local and morphing nature of a given area's sense of time, kind of like how language is thought of, I guess?
As long as people realize that these locales are not equivalent to i18n/l10n locales; a given timezone (using Paul's terminology) may contain multiple i18n/l10n locales (e.g., America/Toronto has both en_CA and fr_CA locales, at minimum) and a given i18n/l10n locale may contain multiple timezones (en_US has several of them, as does pt_BR, for example).
On Dec 21, 2023, at 18:20, Guy Harris <gharris@sonic.net> wrote:
On Dec 21, 2023, at 3:12 PM, Dale Ghent via tz <tz@iana.org> wrote:
Because of those innately human and arbitrary differences, I've always wondered if the TZDB should be thought of more as a "time locale database." This is borrowing a concept from the internationalization and localization (i18n, i10n) systems in computing that exist to address another innately human thing - language. I feel like use of "locale" to describe these entries in the TZDB (TLDB?) better-conveys the local and morphing nature of a given area's sense of time, kind of like how language is thought of, I guess?
As long as people realize that these locales are not equivalent to i18n/l10n locales; a given timezone (using Paul's terminology) may contain multiple i18n/l10n locales (e.g., America/Toronto has both en_CA and fr_CA locales, at minimum) and a given i18n/l10n locale may contain multiple timezones (en_US has several of them, as does pt_BR, for example).
Oh, in no way did I suggest that time?zones be directly linked to language or geographic i18n/i10n locales. I am just borrowing the term those systems use to describe their application and suggesting that "locale" may also have a more apropos meaning here, compared to "zone." It would be a stark differentiator to denote an important difference between the large and faceless Standard Time Zones, and the more local, arbitrary, ever-morphing and, some might say, human locale-specific rules that convey time. It removes the ambiguity of "timezone" and "time zone", two terms that lose all distinction in conversation and (probably) also in translation. That token bit of whitespace jammed (or removed from) between the words isn't very portable, let alone an obvious cue to most. IMO, the distinction between "timezone" and "time zone" doesn't have much reach beyond this mailing list. Anyway, I don't want to start or sustain a debate over whether anyone should drop everything and rename this entire thing. The philosophy of time?zones interest me and I enjoy the discussions here that involve history, politics, and other aspects of making time what it is and was. /dale <lurk>
On Dec 21, 2023, at 4:07 PM, Dale Ghent <daleg@elemental.org> wrote:
Oh, in no way did I suggest that time?zones be directly linked to language or geographic i18n/i10n locales.
I wasn't worried about you, I was worried that *other* people might get confused by the word "locale". If not, great. And, yes, that's the problem with "timezone" vs. "time zone" - they may be too similar, and, when read aloud, they sound too similar unless you make the space between "time" and "zone" into a noticeable pause, and even *that* might not help. That's why I've used "tzdb region" in the past.
Dale Ghent wrote:
IMO, the distinction between "timezone" and "time zone" doesn't have much reach beyond this mailing list.
Indeed, most of my software colleagues write “timezone” without the space, regardless of which sense they mean, even among those who understand the distinction. -- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org
On Thu 2023-12-21T18:12:27-0500 Dale Ghent via tz hath writ:
We all know UTC is not a time zone, but rather a time coordinate. It just happens to coincide with GMT, so why not?
Even here there are problems with historical usage where the terminology does not mean what almost everyone thinks it seems. The value that has been provided using the name GMT started deviating systematically from the mean solar time of the Greenwich meridian in 1901. The convention that drives the deviation is unavoidable because the true goal of the value is to be synchronized worldwide, not to agree with what an astronomer at Greenwich can measure. -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m
participants (5)
-
Dale Ghent -
Doug Ewell -
Guy Harris -
Paul Eggert -
Steve Allen