'Australia/Canberra' time zone?
Hi there I have been a bit surprised that the TZDATA database lacks a listing for "Australia/Canberra", population 350,000. What is the basis for deciding which cities are included or excluded from the database? Does being the national capital, and the major city in its own state/territory warrant inclusion, or is there another criterion? Here is what I believe to be an official source about the Canberra timezone (at least for the present day): https://www.australia.gov.au/about-australia/facts-and-figures/time-zones-an... Cheers JP
On 11/22/19 10:06 PM, John Pye wrote:
What is the basis for deciding which cities are included or excluded from the database? Does being the national capital, and the major city in its own state/territory warrant inclusion, or is there another criterion?
The latter. See <https://data.iana.org/time-zones/theory.html#naming>.
On Nov 23, 2019, at 1:10 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 11/22/19 10:06 PM, John Pye wrote:
What is the basis for deciding which cities are included or excluded from the database? Does being the national capital, and the major city in its own state/territory warrant inclusion, or is there another criterion?
The latter. See <https://data.iana.org/time-zones/theory.html#naming>.
In particular, this means that people shouldn't look for *their* city, or for the major city nearest to them, if they're looking for the name to use in the tzdb ID setting they want. A lot of people in California, for example, will fail to find America/San_Francisco or America/San_Jose in the database, they'll only find America/Los_Angeles even though they're a lot closer to San Francisco or San Jose than they are to Los Angeles. User interfaces for selecting a time zone should not rely on the set of tzdb IDs being a comprehensive list of cities.
On 2019-11-23, at 11:35:43, Guy Harris wrote:
User interfaces for selecting a time zone should not rely on the set of tzdb IDs being a comprehensive list of cities.
Is there an accessible gazetteer, imagemap, or latitude-longitude converter useful for this purpose? My phone does it on request for a built-in set of cities (e.g. Melbourne but not Alice Springs), but it won't display the zoneinfo path. -- gil
On Nov 23, 2019, at 11:03 AM, Paul Gilmartin via tz <tz@iana.org> wrote:
On 2019-11-23, at 11:35:43, Guy Harris wrote:
User interfaces for selecting a time zone should not rely on the set of tzdb IDs being a comprehensive list of cities.
Is there an accessible gazetteer, imagemap, or latitude-longitude converter useful for this purpose?
See https://www.geonames.org/export/web-services.html#timezone although they are rate-limited. I think Ubuntu may do a bulk download of the database and use it for their own server, used for the Ubuntu time-zone-selection mechanism.
My phone does it on request for a built-in set of cities (e.g. Melbourne but not Alice Springs), but it won't display the zoneinfo path.
My phone uses the result it gets from Location Services and turns it into a tzdb ID internally. So does my Mac, and the way I display the zone info path is $ ls -ld /etc/localtime lrwxr-xr-x 1 root wheel 45 Oct 4 03:47 /etc/localtime -> /var/db/timezone/zoneinfo/America/Los_Angeles (your mileage may vary on macOS Catalina if that's on a read-only file system). I don't know whether Apple have their own image maps. This project: https://github.com/evansiroky/timezone-boundary-builder is "A tool to extract data from Open Street Map (OSM) to build the boundaries of the world's timezones." I don't know what geonames.org uses - it may use somebody's shapefiles or it may rely on people associating tzdb IDs with locations.
On 2019-11-23, at 13:18:46, Guy Harris wrote:
See https://www.geonames.org/export/web-services.html#timezone
although they are rate-limited. I think Ubuntu may do a bulk download of the database and use it for their own server, used for the Ubuntu time-zone-selection mechanism.
Thanks. Example http://api.geonames.org/timezone?lat=47.01&lng=10.2&username=demo Produces unrendered XML (CSS somewhere) from which I can copy-and-paste zoneinfo path.
My phone uses the result it gets from Location Services ... (or entered in Settings; limited gazetteer.) ... and turns it into a tzdb ID internally. (but only internally)
... So does my Mac, and the way I display the zone info path is
$ ls -ld /etc/localtime lrwxr-xr-x 1 root wheel 45 Oct 4 03:47 /etc/localtime -> /var/db/timezone/zoneinfo/America/Los_Angeles
(your mileage may vary on macOS Catalina if that's on a read-only file system).
On Mojave, I enabled "Full Disk Access" for Termimal.
I don't know whether Apple have their own image maps. This project:
https://github.com/evansiroky/timezone-boundary-builder
is "A tool to extract data from Open Street Map (OSM) to build the boundaries of the world's timezones." I don't know what geonames.org uses - it may use somebody's shapefiles or it may rely on people associating tzdb IDs with locations.
Thanks again, gil
On 11/23/19 11:03 AM, Paul Gilmartin via tz wrote:
Is there an accessible gazetteer, imagemap, or latitude-longitude converter useful for this purpose?
Yes, see: https://data.iana.org/time-zones/tz-link.html#boundaries tzcode's own tzselect will let you enter geographical coordinates, though lacking boundaries this merely lets tzselect give you nearest cities first, which is not always the best. For example, if you tell tzselect the coordinates for Miami it suggests Cuba, the Bahamas, Jamaica, Quintana Roo, Wayne County KY, Haiti, Switzerland County IN, Panama, Turks & Caicos, and Louisville KY, and never gets around to mentioning the correct entry America/New_York.
Thank you both for the clarification. I understand better now how locations are decided for inclusion in tzdata; it is not at all to do with size/importance as I had assumed, but about maintaining a minimal set of zones with a single representative city from each one selected to be used as the label. Software should never have to ask a 'regular person' what their timezone is, but instead to ask for their location, and then make use of some kind of location-to-timezone lookup routine. https://developers.google.com/maps/documentation/timezone/intro https://metacpan.org/pod/Geo::Location::TimeZone https://pypi.org/project/timezonefinder/ Cheers JP On 24/11/19 5:35 am, Guy Harris wrote:
On Nov 23, 2019, at 1:10 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 11/22/19 10:06 PM, John Pye wrote:
What is the basis for deciding which cities are included or excluded from the database? Does being the national capital, and the major city in its own state/territory warrant inclusion, or is there another criterion? The latter. See <https://data.iana.org/time-zones/theory.html#naming>. In particular, this means that people shouldn't look for *their* city, or for the major city nearest to them, if they're looking for the name to use in the tzdb ID setting they want. A lot of people in California, for example, will fail to find America/San_Francisco or America/San_Jose in the database, they'll only find America/Los_Angeles even though they're a lot closer to San Francisco or San Jose than they are to Los Angeles.
User interfaces for selecting a time zone should not rely on the set of tzdb IDs being a comprehensive list of cities.
On 2019-11-22, at 23:06:01, John Pye wrote:
I have been a bit surprised that the TZDATA database lacks a listing for "Australia/Canberra", population 350,000...
??? Darwin PaulGilm.wifi.belezacoffeebar.com 18.7.0 Darwin Kernel Version 18.7.0: Tue Aug 20 16:57:14 PDT 2019; root:xnu-4903.271.2~2/RELEASE_X86_64 x86_64 637 $ 637 $ ls -l /usr/share/zoneinfo/Australia/Canberra -rw-r--r-- 1 root wheel 2197 Sep 17 15:57 /usr/share/zoneinfo/Australia/Canberra I've seem that on Solaris, Linux, and MacOS for many years that I had colleagues in Canberra. -- gil
Paul Gilmartin via tz <tz@iana.org> writes:
On 2019-11-22, at 23:06:01, John Pye wrote:
I have been a bit surprised that the TZDATA database lacks a listing for "Australia/Canberra", population 350,000...
??? 637 $ ls -l /usr/share/zoneinfo/Australia/Canberra -rw-r--r-- 1 root wheel 2197 Sep 17 15:57 /usr/share/zoneinfo/Australia/Canberra
Yup, it's there, as a link in the "backward" file: Link Australia/Sydney Australia/Canberra I speculate that the OP is on FreeBSD, or some other platform where they don't install the "backwards compatibility" links by default. Maybe we should lobby FreeBSD to install those names so they're more like everybody else. I got burned by their incompatibility in this area just the other day [1]. regards, tom lane [1] https://www.postgresql.org/message-id/flat/12931.1573846697%40sss.pgh.pa.us#...
On 2019-11-23 12:05:11 (-0500), Tom Lane wrote:
Paul Gilmartin via tz <tz@iana.org> writes:
On 2019-11-22, at 23:06:01, John Pye wrote:
I have been a bit surprised that the TZDATA database lacks a listing for "Australia/Canberra", population 350,000...
??? 637 $ ls -l /usr/share/zoneinfo/Australia/Canberra -rw-r--r-- 1 root wheel 2197 Sep 17 15:57 /usr/share/zoneinfo/Australia/Canberra
Yup, it's there, as a link in the "backward" file:
Link Australia/Sydney Australia/Canberra
I speculate that the OP is on FreeBSD, or some other platform where they don't install the "backwards compatibility" links by default.
Maybe we should lobby FreeBSD to install those names so they're more like everybody else. I got burned by their incompatibility in this area just the other day [1].
regards, tom lane
[1] https://www.postgresql.org/message-id/flat/12931.1573846697%40sss.pgh.pa.us#...
I can probably be convinced to change that with the next update. ;-) I've made a note. I follow tzdata releases pretty closely and try not to diverge from upstream. Not installing backzone links predates my maintaining tzdata in FreeBSD. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
On November 23, 2019 10:56:28 PM EST, Philip Paeps <philip@trouble.is> wrote:
I follow tzdata releases pretty closely and try not to diverge from upstream. Not installing backzone links predates my maintaining tzdata
in FreeBSD.
I chose not to install the "backward" zones in the hope that this would more securely deprecate the then-recently-obsoleted old-style names like "US/Eastern", and then maybe they could be completely removed from the distribution if other downstream consumers (only a few operating systems at that point, no language runtimes) would do likewise. Unfortunately, these ancient compatibility links never got deleted, so "backward" now contains a mix of ancient and more recent compatibility links, and users are still using them (or being told to use them by documentation that should have been updated decades ago). -GAWollman
On 2019-11-24 16:13:57 (+1000), Garrett Wollman wrote:
On November 23, 2019 10:56:28 PM EST, Philip Paeps <philip@trouble.is> wrote:
I follow tzdata releases pretty closely and try not to diverge from upstream. Not installing backzone links predates my maintaining tzdata in FreeBSD.
I chose not to install the "backward" zones in the hope that this would more securely deprecate the then-recently-obsoleted old-style names like "US/Eastern", and then maybe they could be completely removed from the distribution if other downstream consumers (only a few operating systems at that point, no language runtimes) would do likewise.
Unfortunately, these ancient compatibility links never got deleted, so "backward" now contains a mix of ancient and more recent compatibility links, and users are still using them (or being told to use them by documentation that should have been updated decades ago).
Thanks for the context, Garrett. I have no strong opinion about whether to install the backzone links in FreeBSD or not. If the majority of other operating systems install them though, FreeBSD should probably do so as well. If we're currently the only ones not installing the backzone links ... that's just silly. :-) Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
On 24/11/2019 06:22, Philip Paeps wrote:
I have no strong opinion about whether to install the backzone links in FreeBSD or not.
Since backzone is the ONLY place that has correct TZ data for the islands around the UK then leaving it out is putting invalid data for those and other timezones. ... -- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.uk/wiki/Contact L.S.Caine Electronic Services - https://lsces.uk Model Engineers Digital Workshop - https://medw.uk Rainbow Digital Media - https://rainbowdigitalmedia.uk
"Philip Paeps" <philip@trouble.is> writes:
I have no strong opinion about whether to install the backzone links in FreeBSD or not. If the majority of other operating systems install them though, FreeBSD should probably do so as well. If we're currently the only ones not installing the backzone links ... that's just silly. :-)
I can't claim to have surveyed everything, but I have personal experience with Debian, Red Hat, NetBSD, OpenBSD, and macOS, and they all ship the backzone links. regards, tom lane
On 2019-11-25 00:03:42 (+0800), Tom Lane wrote:
"Philip Paeps" <philip@trouble.is> writes:
I have no strong opinion about whether to install the backzone links in FreeBSD or not. If the majority of other operating systems install them though, FreeBSD should probably do so as well. If we're currently the only ones not installing the backzone links ... that's just silly. :-)
I can't claim to have surveyed everything, but I have personal experience with Debian, Red Hat, NetBSD, OpenBSD, and macOS, and they all ship the backzone links.
Thanks for confirming that. I'll install the backward (not backzone) links in FreeBSD when I import the next update of tzdata. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
On 2019-11-25 11:21:52 (+0800), Philip Paeps wrote:
On 2019-11-25 00:03:42 (+0800), Tom Lane wrote:
"Philip Paeps" <philip@trouble.is> writes:
I have no strong opinion about whether to install the backzone links in FreeBSD or not. If the majority of other operating systems install them though, FreeBSD should probably do so as well. If we're currently the only ones not installing the backzone links ... that's just silly. :-)
I can't claim to have surveyed everything, but I have personal experience with Debian, Red Hat, NetBSD, OpenBSD, and macOS, and they all ship the backzone links.
Thanks for confirming that.
I'll install the backward (not backzone) links in FreeBSD when I import the next update of tzdata.
I imported tzdata2020a into FreeBSD-head a couple of hours ago (soon after I saw Paul's release announcement). When I went to install the backward links as promised, I noticed that Xin Li already made that change two weeks ago. https://svnweb.freebsd.org/base/head/share/zoneinfo/Makefile?revision=359736... This should bring FreeBSD closer to other operating systems. (I still have a long-standing todo item to bring tzcode into the last decade, and possibly even the next one.) Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
On 11/23/19 10:22 PM, Philip Paeps wrote:
On 2019-11-24 16:13:57 (+1000), Garrett Wollman wrote:
I chose not to install the "backward" zones in the hope that this would more securely deprecate the then-recently-obsoleted old-style names like "US/Eastern"
I have no strong opinion about whether to install the backzone links in FreeBSD or not.
Hold on a second: although Garrett wrote "backward", you and Tom wrote "backzone". They're quite different things. Although many OSes install the links in the "backward" file, the "backzone" file is not recommended (see its comments for why). So I assume you meant "backward", not "backzone". (This is in contrast to Lester's followup email, which said "backzone" and was actually about the "backzone" file.) Maybe we should rename "backzone" to avoid future confusion like this. It's not a file people should normally want to use anyway.
Paul Eggert <eggert@cs.ucla.edu> writes:
Hold on a second: although Garrett wrote "backward", you and Tom wrote "backzone". They're quite different things. Although many OSes install the links in the "backward" file, the "backzone" file is not recommended (see its comments for why). So I assume you meant "backward", not "backzone".
Oh, thanks for the correction. I did mean "backward". BTW, it's not like the tz project isn't taking a position on this: by including backward and not backzone in the standard tzdata.zi file, I'd say a pretty clear precedent for what to include has been established. regards, tom lane
On 2019-11-25 04:52:23 (+0800), Paul Eggert wrote:
On 11/23/19 10:22 PM, Philip Paeps wrote:
On 2019-11-24 16:13:57 (+1000), Garrett Wollman wrote:
I chose not to install the "backward" zones in the hope that this would more securely deprecate the then-recently-obsoleted old-style names like "US/Eastern"
I have no strong opinion about whether to install the backzone links in FreeBSD or not.
Hold on a second: although Garrett wrote "backward", you and Tom wrote "backzone". They're quite different things. Although many OSes install the links in the "backward" file, the "backzone" file is not recommended (see its comments for why). So I assume you meant "backward", not "backzone".
I did mean "backward", not "backzone". Apologies for the confusion!
(This is in contrast to Lester's followup email, which said "backzone" and was actually about the "backzone" file.)
Maybe we should rename "backzone" to avoid future confusion like this. It's not a file people should normally want to use anyway.
Renaming "backzone" might frustrate people who do rely on it though ... maybe this is a sufficiently minor issue that can simply be left alone. Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
participants (8)
-
Garrett Wollman -
Guy Harris -
John Pye -
Lester Caine -
Paul Eggert -
Paul Gilmartin -
Philip Paeps -
Tom Lane