[tz] Definition of "timezone"

[Guy Harris]

On Dec 21, 2023, at 12:01 PM, Paul Eggert via tz <tz at 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-pcapng.html#name-interface-description-block

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?