Is there a simple way to compile only the timezones ? i.e. US/Central etc... No cities ? -- // Karlsson
On Feb 25, 2021, at 3:18 PM, William Karlsson via tz <tz@iana.org> wrote:
Is there a simple way to compile only the timezones ? i.e. US/Central etc... No cities ?
No. The best way to think of the database, the "z" in "tzdb" and "tz@iana.org" and the "zone" in "time zone database" notwithstanding, is as a database of *regions*, not "time zones". For one thing, a time zone, in the usual sense, can include locations that don't follow the same daylight saving time rules; for example, the Mountain Time Zone in the US includes Arizona, which (outside of the Navajo Nation) doesn't follow DST, as well as several states that do. In addition, a given location can move from one time zone to another. Even when the pre-city names were the primary names in the tzdb, the database didn't have "only the timezones". It had a region named "US/Mountain", but it also had a region named "US/Arizona", for the reason mentioned above, along with US/East-Indiana and US/Indiana-Starke. To quote the theory.html file: 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, America/Mazatlan which observes Mexican-style 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, andAmerica/Hermosillo, each of which currently uses mountain time but differs from other timezones for some timestamps after 1970. The city names were chosen a while ago as the way to identify regions. The source files for the database have entries for regions ("timezones"), not for "traditional time zones"; it produces files for all the regions, and then constructs backward compatibility links, using the old names, from the "backward" file. What are you trying to accomplish here?
On Thu, 25 Feb 2021 at 18:20, William Karlsson via tz <tz@iana.org> wrote:
Is there a simple way to compile only the timezones ? i.e. US/Central etc... No cities ?
In short, no. Most of the identifiers of that type are merely backwards compatibility links to other zones named in the conventional way, like America/Chicago, and so can't really be compiled alone. See the 'backward' file. Slightly longer, the notion of a "time zone" as you describe is ("Eastern", "Central", etc.) is actually quite ill-defined. While in the US, we are accustomed to a certain level of legislated uniformity in our timekeeping, in other parts of the world, clocks in various countries and regions often agree (or disagree) with their neighbors' out of coincidence arising from mutual convenience. For example, there is not really such a thing as "Central African Time" as a standard that is to be followed; rather, there just happen to be countries and regions that, for their various reasons, choose to observe UTC+2, and "Central African Time" is a name that some have used to describe that common trait to facilitate communication. Even within the US, where your concept of "time zones" is a bit better defined: Clocks in Phoenix match Denver in the winter time, but match Los Angeles in the summer. Is that best described as "Mountain"? Or "Pacific"? Is it both, neither, or something altogether different? Depending on the precise questions you're asking, that can get complicated quickly, before questions of how historical timekeeping practices diverged in neighboring regions even come up. These are the main factors contributing to the approach our database takes instead: Provide a representative location for each region where clocks have agreed since an arbitrary cutoff (in our case, 1970). In particular, there are generally many such regions ("time zones" in our technical sense) within what we might think of as a "time zone" in a more cultural sense. For more detail, see the "Scope of the tz database" and "Timezone identifiers" sections of 'theory.html'. * * * On the other hand, if you're really just looking for the nautical/navigational "zones" that form 15-degree-wide bands from pole to pole and don't account for geopolitical boundaries or any civil quirks like Daylight Saving Time, the 'etcetera' file has those; however, their limited utility makes them ill-suited for most real-world applications, and again, they are only really present for backwards compatibility. (Most confusingly the +/- signs in those names are the opposite of the now-standard conventions.) I would advise against their use in anything new. We may be able to point you in a better direction if you'd tell us more about what you're specifically trying to accomplish. -- Tim Parenti
participants (3)
-
Guy Harris -
Tim Parenti -
William Karlsson