It would be nice if Montreal was included in your database. There are smaller cities that are listed. I am using the latest Linux Mint Mate (18.2) and i had to choose Toronto to get into the right timezone. Montreal is not there. It doesn't matter much to me but there are some people here who will find it strange. Toronto is like... in another country. It's about History and the French people in Canada... [1492899431935_logo3-rouge+gris-Sb=64px.png] <https://sites.google.com/view/sb-junior/> sites.google.com/ <https://sites.google.com/view/sb-junior/>view/sb-junior/<https://sites.google.com/view/sb-junior/><https://sites.google.com/view/sb-junior/><https://sites.google.com/view/sb-junior/>
Sébastien Bouchard wrote:
It would be nice if Montreal was included in your database. There are smaller cities that are listed.
Yes, some small cities are listed, like Blanc-Sablon. However, some large cities are omitted. Beijing, for example, is not listed even though it's larger than Toronto. The listing criteria are here: https://www.iana.org/time-zones/repository/theory.html One guideline is, "If all the clocks in a region have agreed since 1970, don't bother to include more than one location even if subregions' clocks disagreed before 1970." Montreal has agreed with Toronto since 1970 so it's in the same region as Toronto, and we'd rather not have multiple names for the same region. If we added Montreal, then Québec would want in too, and after that Gatineau, and Sherbrooke, and Trois-Rivières - and how could we say no to Saguenay? We lack the resources to manage all these names so we list only the largest city in each region, which in your case is Toronto.
Sebastien Bouchard wrote:
It would be nice if Montreal was included in your database. There are smaller cities that are listed.
That's not the criterion that we use to determine what goes in the database. It's not a database of cities but of timezones. Montreal and Toronto, for all their cultural differences, have had their clocks set the same way continuously since our threshold date of 1970, along with most of the rest of Quebec and Ontario. This makes a single timezone for our purposes, and our reference point within that timezone is, as is usually the case, the largest city in the zone, which is Toronto. -zefram
On Nov 11, 2017, at 5:27 PM, Zefram <zefram@fysh.org> wrote:
It's not a database of cities but of timezones.
So every UI that offers a list of tzdb names (or tzdb names slightly tweaked by replacing underscores with blanks, or whatever) as if it were a list of cities is broken. If that's what Linux Mint offers, the developers of the GUI it offers to choose a time zone should look at how Apple does it. No tzdb zone names visible whatsoever; just a map where you can pick your location, a text box in which you can see a drop-down list of cities near the location or type in a city name (and, yes, they have Montreal), and an option to just let the system pick the time zone automatically (presumably it uses Location Services, which, on a Mac, uses Wi-Fi and, presumably, a database of networks, and looks the location up in a map). (Speaking of Apple: Deborah, does this: https://support.apple.com/en-us/HT206986 mean Apple's now sending tzdb updates out independently of release updates?)
On 2017-11-11 18:06:51 (-0800), Guy Harris wrote:
(Speaking of Apple: Deborah, does this:
https://support.apple.com/en-us/HT206986
mean Apple's now sending tzdb updates out independently of release updates?)
I've had anecdotal reports from friends in Sudan that this is indeed happening. Very nice! The mechanism seems similar to carrier data updates. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
(Speaking of Apple: Deborah, does this:
https://support.apple.com/en-us/HT206986
mean Apple's now sending tzdb updates out independently of release updates?)
The updates described by that support article do include the TZ database, and the updates are distributed independently of OS software updates. The article also describes the minimum OS releases that support this. Debbie
On Nov 11, 2017, at 9:06 PM, Guy Harris <guy@alum.mit.edu> wrote:
On Nov 11, 2017, at 5:27 PM, Zefram <zefram@fysh.org> wrote:
It's not a database of cities but of timezones.
So every UI that offers a list of tzdb names (or tzdb names slightly tweaked by replacing underscores with blanks, or whatever) as if it were a list of cities is broken.
If that's what Linux Mint offers, the developers of the GUI it offers to choose a time zone should look at how Apple does it. No tzdb zone names visible whatsoever; just a map where you can pick your location, a text box in which you can see a drop-down list of cities near the location or type in a city name (and, yes, they have Montreal), and an option to just let the system pick the time zone automatically (presumably it uses Location Services, which, on a Mac, uses Wi-Fi and, presumably, a database of networks, and looks the location up in a map).
(Speaking of Apple: Deborah, does this:
https://support.apple.com/en-us/HT206986
mean Apple's now sending tzdb updates out independently of release updates?)
On Nov 11, 2017, at 9:06 PM, Guy Harris <guy@alum.mit.edu> wrote:
On Nov 11, 2017, at 5:27 PM, Zefram <zefram@fysh.org> wrote:
It's not a database of cities but of timezones.
So every UI that offers a list of tzdb names (or tzdb names slightly tweaked by replacing underscores with blanks, or whatever) as if it were a list of cities is broken.
No. Tzdb isn't a UI, and doesn't define a UI. UI design is a separate activity, and it's not constrained by tzdb. It would be perfectly valid to offer a UI that has 10k city names in it as a way to set the correct tz for your system. paul
I'm pretty sure that's what Guy is saying. If you define your UI based on tzdb zone names, your UI is broken. On November 13, 2017 9:17:55 AM EST, Paul.Koning@dell.com wrote:
On Nov 11, 2017, at 9:06 PM, Guy Harris <guy@alum.mit.edu> wrote:
On Nov 11, 2017, at 5:27 PM, Zefram <zefram@fysh.org> wrote:
It's not a database of cities but of timezones.
So every UI that offers a list of tzdb names (or tzdb names slightly tweaked by replacing underscores with blanks, or whatever) as if it were a list of cities is broken.
No. Tzdb isn't a UI, and doesn't define a UI. UI design is a separate activity, and it's not constrained by tzdb. It would be perfectly valid to offer a UI that has 10k city names in it as a way to set the correct tz for your system.
paul
Date: Mon, 13 Nov 2017 14:20:08 +0000 From: Paul G <paul@ganssle.io> Message-ID: <8BDF3C45-0FD2-4D54-939B-F4B20E5DE70D@ganssle.io> | I'm pretty sure that's what Guy is saying. If you define your UI based on | tzdb zone names, your UI is broken. Not broken, just less than optimal for some user classes. Like the type that want city XXX listed, because "that's our capital" or because "that lot don't speak French" or ... For example, the NetBSD UI for changing the timezone, or setting it after initial installation (if it wasn't done then) is: ln -sf /usr/share/zoneinfo/xxx/yyy /etc/localtime or echo export TZ=xxx/yyy >> .profile or similar (depending upon what kind of change is being made.) Discovering what to use for xxx/yyy is left to the user (tzselect is not installed.) That works just fine, and is entirely suitable for the kinds of users NetBSD tends to attract. kre ps: there is a menu based approach available during system installation to make this a little easier for first time users.
Well, I was just trying to clarify what it seemed like Guy was saying. If you're using tzdb names and aliases as a list of cities where the time zone applies, your UI is more or less broken, since tzdb uses a specific, historically-contingent subset of those cities and other aliases as the names of the zones. What I will say is that while it's probably not going to kill your application if you do this, it's definitely not great UI. I remember before I knew anything about time zones or tzdb I would set up computers and find that if I wanted central time, I could only set up America/Chicago - what were the implications of that if I was in Houston? Why wasn't Houston on the map? How do I even know that Chicago is on Central time? Same for anyone in San Francisco whose only choice is Los Angeles. You're basically exposing an implementation detail of the database (the primary key which happens to be human-readable) in your UI, which is a lazy and confusing design. Not to mention it doesn't come with localization. If you want to say, "Here's a crude UI that lets you select tzdb keys, which are often named after cities", that's fine, but if you want a good user experience (even for people with no political agenda), you should probably design something where the workflow is more like "Tell me where you are (some way to select this - possibly a list of all major cities) and I'll set your time zone appropriately (or give you options if you're in some weird edge case where it may be uncertain which time zone rules you're using)." This has been fleshed out in many threads on this mailing list in the past, I don't think it's particularly controversial to say that "the key names should be user-friendly" is not within the scope of this project. On 11/13/2017 12:01 PM, Robert Elz wrote:
Date: Mon, 13 Nov 2017 14:20:08 +0000 From: Paul G <paul@ganssle.io> Message-ID: <8BDF3C45-0FD2-4D54-939B-F4B20E5DE70D@ganssle.io>
| I'm pretty sure that's what Guy is saying. If you define your UI based on | tzdb zone names, your UI is broken.
Not broken, just less than optimal for some user classes. Like the type that want city XXX listed, because "that's our capital" or because "that lot don't speak French" or ...
For example, the NetBSD UI for changing the timezone, or setting it after initial installation (if it wasn't done then) is:
ln -sf /usr/share/zoneinfo/xxx/yyy /etc/localtime or echo export TZ=xxx/yyy >> .profile
or similar (depending upon what kind of change is being made.)
Discovering what to use for xxx/yyy is left to the user (tzselect is not installed.)
That works just fine, and is entirely suitable for the kinds of users NetBSD tends to attract.
kre
ps: there is a menu based approach available during system installation to make this a little easier for first time users.
On Nov 13, 2017, at 9:29 AM, Paul G <paul@ganssle.io> wrote:
Well, I was just trying to clarify what it seemed like Guy was saying. If you're using tzdb names and aliases as a list of cities where the time zone applies, your UI is more or less broken, since tzdb uses a specific, historically-contingent subset of those cities and other aliases as the names of the zones.
What I will say is that while it's probably not going to kill your application if you do this, it's definitely not great UI. I remember before I knew anything about time zones or tzdb I would set up computers and find that if I wanted central time, I could only set up America/Chicago - what were the implications of that if I was in Houston? Why wasn't Houston on the map? How do I even know that Chicago is on Central time? Same for anyone in San Francisco whose only choice is Los Angeles.
You're basically exposing an implementation detail of the database (the primary key which happens to be human-readable) in your UI, which is a lazy and confusing design. Not to mention it doesn't come with localization. If you want to say, "Here's a crude UI that lets you select tzdb keys, which are often named after cities", that's fine, but if you want a good user experience (even for people with no political agenda), you should probably design something where the workflow is more like "Tell me where you are (some way to select this - possibly a list of all major cities) and I'll set your time zone appropriately (or give you options if you're in some weird edge case where it may be uncertain which time zone rules you're using)."
This has been fleshed out in many threads on this mailing list in the past, I don't think it's particularly controversial to say that "the key names should be user-friendly" is not within the scope of this project.
Yes. That's *exactly* my point.
Date: Mon, 13 Nov 2017 12:29:46 -0500 From: Paul G <paul@ganssle.io> Message-ID: <60a4872d-b880-3b6e-7e73-62ac02450feb@ganssle.io> | I don't think it's particularly controversial to say that "the key names | should be user-friendly" is not within the scope of this project. I agree totally with the "not within the scope" -- my point was that what is "friendly" to one user, is an irritation to others. I simply could not tolerate any of the options you proposed, I know what timezone I want, and what its name is, (for any of the various places I am sometimes located) and I simply want to set it. As I understand it (not being a MacOS user) the UI that Guy mentioned requires a GUI for example - something I very often am not using (not all computers, especially not all on which NetBSD runs, have any kind of bit-mapped display. Several systems offer only a text based console. They still need to be able to set their timezone -- and consider the setting for the clocks that have been mentioned in another thread. I don't know what hardware that plans on using for its time display, but digital clocks often just use large 7-segment leds, and analog ones...) kre
On Nov 13, 2017, at 9:01 AM, Robert Elz <kre@munnari.OZ.AU> wrote:
Date: Mon, 13 Nov 2017 14:20:08 +0000 From: Paul G <paul@ganssle.io> Message-ID: <8BDF3C45-0FD2-4D54-939B-F4B20E5DE70D@ganssle.io>
| I'm pretty sure that's what Guy is saying. If you define your UI based on | tzdb zone names, your UI is broken.
Not broken, just less than optimal for some user classes. Like the type that want city XXX listed, because "that's our capital" or because "that lot don't speak French" or ...
What I said was So every UI that offers a list of tzdb names (or tzdb names slightly tweaked by replacing underscores with blanks, or whatever) as if it were a list of cities is broken. If your UI is intended *solely* for people who understand what tzdb names are - i.e., they are strings that happen to use city names as a component, but are *not* identifiers for *your* city - then using tzdb names is OK. If your UI is expected to be used by people who *aren't* familiar with tzdb names, it should not use tzdb names, whether it's a GUI interface or not.
Date: Mon, 13 Nov 2017 12:12:51 -0800 From: Guy Harris <guy@alum.mit.edu> Message-ID: <1331A59A-26DB-4D0B-8BC2-07448C5F1874@alum.mit.edu> | If your UI is expected to be used by people who *aren't* familiar | with tzdb names, it should not use tzdb names, whether it's a GUI | interface or not. The standard way to find out the time in some specified location is TZ=something date [+%...] (in scripts, or on the command line). If the "something" is not to be a tzdb name, what do you suggest using ? If tzdb names are to be used there, how would you suggest explaining to users how that one method is to be used in one place, and a different method in a different place? Like it or not, the tzdb identifiers *are* the identifiers used to name and select time zones. As long as we don't try and read more into them, than that they are timezone identifiers, that's fine by me. kre
On Nov 13, 2017, at 2:57 PM, Robert Elz <kre@munnari.OZ.AU> wrote:
Date: Mon, 13 Nov 2017 12:12:51 -0800 From: Guy Harris <guy@alum.mit.edu> Message-ID: <1331A59A-26DB-4D0B-8BC2-07448C5F1874@alum.mit.edu>
| If your UI is expected to be used by people who *aren't* familiar | with tzdb names, it should not use tzdb names, whether it's a GUI | interface or not.
The standard way to find out the time in some specified location is
TZ=something date [+%...]
(in scripts, or on the command line).
If the "something" is not to be a tzdb name, what do you suggest using ?
I suggest having command that takes a location and prints out the tzdb name for the location: TZ=`tzid San Francisco` date or something such as that. "America/Los_Angeles" isn't a location, it's a tzid. "Los Angeles", "San Francisco", "Pinole", etc. are locations. For example, Apple appears to have an SQLite database /System/Library/PrivateFrameworks/GeoKit.framework/Resources/world.geokit: sqlite> .tables ZGEOKITPLACE ZGEOPLACENAME Z_METADATA Z_MODELCACHE Z_PRIMARYKEY sqlite> .schema CREATE TABLE ZGEOKITPLACE ( Z_PK INTEGER PRIMARY KEY, Z_ENT INTEGER, Z_OPT INTEGER, ZEMBARGO INTEGER, ZGEONAMEID INTEGER, ZPOPULATION INTEGER, ZELEVATION INTEGER, ZISCAPITAL INTEGER, ZCOUNTRY INTEGER, ZAREA INTEGER, ZLATITUDE FLOAT, ZLONGITUDE FLOAT, ZNAME VARCHAR, ZREGIONALCODE VARCHAR, ZTIMEZONENAME VARCHAR, ZCODE VARCHAR, ZLANGUAGES VARCHAR ); CREATE TABLE ZGEOPLACENAME ( Z_PK INTEGER PRIMARY KEY, Z_ENT INTEGER, Z_OPT INTEGER, ZAR INTEGER, ZCA INTEGER, ZCS INTEGER, ZDA INTEGER, ZDE INTEGER, ZEL INTEGER, ZEN INTEGER, ZES INTEGER, ZFI INTEGER, ZFR INTEGER, ZHE INTEGER, ZHR INTEGER, ZHU INTEGER, ZID INTEGER, ZIT INTEGER, ZJA INTEGER, ZKO INTEGER, ZMS INTEGER, ZNL INTEGER, ZNO INTEGER, ZPL INTEGER, ZPT INTEGER, ZPT_BR INTEGER, ZRO INTEGER, ZRU INTEGER, ZSK INTEGER, ZSV INTEGER, ZTH INTEGER, ZTR INTEGER, ZUK INTEGER, ZVI INTEGER, ZZH INTEGER, ZZH_TW INTEGER, ZPLACE INTEGER, Z1_PLACE INTEGER, ZNAME VARCHAR ); CREATE INDEX ZGEOKITPLACE_ZGEONAMEID_INDEX ON ZGEOKITPLACE (ZGEONAMEID); CREATE INDEX ZGEOKITPLACE_ZLATITUDE_INDEX ON ZGEOKITPLACE (ZLATITUDE); CREATE INDEX ZGEOKITPLACE_ZLONGITUDE_INDEX ON ZGEOKITPLACE (ZLONGITUDE); CREATE INDEX ZGEOKITPLACE_ZPOPULATION_INDEX ON ZGEOKITPLACE (ZPOPULATION); CREATE INDEX ZGEOKITPLACE_ZISCAPITAL_INDEX ON ZGEOKITPLACE (ZISCAPITAL); CREATE INDEX ZGEOKITPLACE_ZTIMEZONENAME_INDEX ON ZGEOKITPLACE (ZTIMEZONENAME); CREATE INDEX ZGEOKITPLACE_ZCOUNTRY_INDEX ON ZGEOKITPLACE (ZCOUNTRY); CREATE INDEX ZGEOKITPLACE_ZCODE_INDEX ON ZGEOKITPLACE (ZCODE); CREATE INDEX ZGEOKITPLACE_Z_ENT_INDEX ON ZGEOKITPLACE (Z_ENT); CREATE INDEX ZGEOPLACENAME_ZDA_INDEX ON ZGEOPLACENAME (ZDA); CREATE INDEX ZGEOPLACENAME_ZDE_INDEX ON ZGEOPLACENAME (ZDE); CREATE INDEX ZGEOPLACENAME_ZEN_INDEX ON ZGEOPLACENAME (ZEN); CREATE INDEX ZGEOPLACENAME_ZES_INDEX ON ZGEOPLACENAME (ZES); CREATE INDEX ZGEOPLACENAME_ZFI_INDEX ON ZGEOPLACENAME (ZFI); CREATE INDEX ZGEOPLACENAME_ZFR_INDEX ON ZGEOPLACENAME (ZFR); CREATE INDEX ZGEOPLACENAME_ZIT_INDEX ON ZGEOPLACENAME (ZIT); CREATE INDEX ZGEOPLACENAME_ZJA_INDEX ON ZGEOPLACENAME (ZJA); CREATE INDEX ZGEOPLACENAME_ZKO_INDEX ON ZGEOPLACENAME (ZKO); CREATE INDEX ZGEOPLACENAME_ZNAME_INDEX ON ZGEOPLACENAME (ZNAME); CREATE INDEX ZGEOPLACENAME_ZNL_INDEX ON ZGEOPLACENAME (ZNL); CREATE INDEX ZGEOPLACENAME_ZNO_INDEX ON ZGEOPLACENAME (ZNO); CREATE INDEX ZGEOPLACENAME_ZPL_INDEX ON ZGEOPLACENAME (ZPL); CREATE INDEX ZGEOPLACENAME_ZPT_INDEX ON ZGEOPLACENAME (ZPT); CREATE INDEX ZGEOPLACENAME_ZPT_BR_INDEX ON ZGEOPLACENAME (ZPT_BR); CREATE INDEX ZGEOPLACENAME_ZRU_INDEX ON ZGEOPLACENAME (ZRU); CREATE INDEX ZGEOPLACENAME_ZSV_INDEX ON ZGEOPLACENAME (ZSV); CREATE INDEX ZGEOPLACENAME_ZZH_INDEX ON ZGEOPLACENAME (ZZH); CREATE INDEX ZGEOPLACENAME_ZZH_TW_INDEX ON ZGEOPLACENAME (ZZH_TW); CREATE INDEX ZGEOPLACENAME_ZPLACE_INDEX ON ZGEOPLACENAME (ZPLACE); CREATE INDEX ZGEOPLACENAME_Z_ENT_INDEX ON ZGEOPLACENAME (Z_ENT); CREATE TABLE Z_PRIMARYKEY (Z_ENT INTEGER PRIMARY KEY, Z_NAME VARCHAR, Z_SUPER INTEGER, Z_MAX INTEGER); CREATE TABLE Z_METADATA (Z_VERSION INTEGER PRIMARY KEY, Z_UUID VARCHAR(255), Z_PLIST BLOB); CREATE TABLE Z_MODELCACHE (Z_CONTENT BLOB); I haven't fired up Mike T's SQLite Database App to try to figure out how to use it to translate a city name to a tzid, but that might be one way to implement the tzid command.
Like it or not, the tzdb identifiers *are* the identifiers used to name and select time zones.
They are the identifiers used to *identify* time zones. They should not be the only way to *select* time zones; UIs should be offered that allow people to specify a location and have code figure out the time zone.
There are github.com/evansiroky/timezone-boundary-builder that do this. Responding to topic discussed earlier on the list, I believe most of those large software publisher deviate from the official tz database in some ways. Most of those software and system available on the market put Asia/Urumqi on +8 while tzdb have it +6. 2017年11月14日 07:28 於 "Guy Harris" <guy@alum.mit.edu> 寫道：
On Nov 13, 2017, at 2:57 PM, Robert Elz <kre@munnari.OZ.AU> wrote:
Date: Mon, 13 Nov 2017 12:12:51 -0800 From: Guy Harris <guy@alum.mit.edu> Message-ID: <1331A59A-26DB-4D0B-8BC2-07448C5F1874@alum.mit.edu>
| If your UI is expected to be used by people who *aren't* familiar | with tzdb names, it should not use tzdb names, whether it's a GUI | interface or not.
The standard way to find out the time in some specified location is
TZ=something date [+%...]
(in scripts, or on the command line).
If the "something" is not to be a tzdb name, what do you suggest using ?
I suggest having command that takes a location and prints out the tzdb name for the location:
TZ=`tzid San Francisco` date
or something such as that. "America/Los_Angeles" isn't a location, it's a tzid. "Los Angeles", "San Francisco", "Pinole", etc. are locations.
For example, Apple appears to have an SQLite database /System/Library/ PrivateFrameworks/GeoKit.framework/Resources/world.geokit:
sqlite> .tables ZGEOKITPLACE ZGEOPLACENAME Z_METADATA Z_MODELCACHE Z_PRIMARYKEY sqlite> .schema CREATE TABLE ZGEOKITPLACE ( Z_PK INTEGER PRIMARY KEY, Z_ENT INTEGER, Z_OPT INTEGER, ZEMBARGO INTEGER, ZGEONAMEID INTEGER, ZPOPULATION INTEGER, ZELEVATION INTEGER, ZISCAPITAL INTEGER, ZCOUNTRY INTEGER, ZAREA INTEGER, ZLATITUDE FLOAT, ZLONGITUDE FLOAT, ZNAME VARCHAR, ZREGIONALCODE VARCHAR, ZTIMEZONENAME VARCHAR, ZCODE VARCHAR, ZLANGUAGES VARCHAR ); CREATE TABLE ZGEOPLACENAME ( Z_PK INTEGER PRIMARY KEY, Z_ENT INTEGER, Z_OPT INTEGER, ZAR INTEGER, ZCA INTEGER, ZCS INTEGER, ZDA INTEGER, ZDE INTEGER, ZEL INTEGER, ZEN INTEGER, ZES INTEGER, ZFI INTEGER, ZFR INTEGER, ZHE INTEGER, ZHR INTEGER, ZHU INTEGER, ZID INTEGER, ZIT INTEGER, ZJA INTEGER, ZKO INTEGER, ZMS INTEGER, ZNL INTEGER, ZNO INTEGER, ZPL INTEGER, ZPT INTEGER, ZPT_BR INTEGER, ZRO INTEGER, ZRU INTEGER, ZSK INTEGER, ZSV INTEGER, ZTH INTEGER, ZTR INTEGER, ZUK INTEGER, ZVI INTEGER, ZZH INTEGER, ZZH_TW INTEGER, ZPLACE INTEGER, Z1_PLACE INTEGER, ZNAME VARCHAR ); CREATE INDEX ZGEOKITPLACE_ZGEONAMEID_INDEX ON ZGEOKITPLACE (ZGEONAMEID); CREATE INDEX ZGEOKITPLACE_ZLATITUDE_INDEX ON ZGEOKITPLACE (ZLATITUDE); CREATE INDEX ZGEOKITPLACE_ZLONGITUDE_INDEX ON ZGEOKITPLACE (ZLONGITUDE); CREATE INDEX ZGEOKITPLACE_ZPOPULATION_INDEX ON ZGEOKITPLACE (ZPOPULATION); CREATE INDEX ZGEOKITPLACE_ZISCAPITAL_INDEX ON ZGEOKITPLACE (ZISCAPITAL); CREATE INDEX ZGEOKITPLACE_ZTIMEZONENAME_INDEX ON ZGEOKITPLACE (ZTIMEZONENAME); CREATE INDEX ZGEOKITPLACE_ZCOUNTRY_INDEX ON ZGEOKITPLACE (ZCOUNTRY); CREATE INDEX ZGEOKITPLACE_ZCODE_INDEX ON ZGEOKITPLACE (ZCODE); CREATE INDEX ZGEOKITPLACE_Z_ENT_INDEX ON ZGEOKITPLACE (Z_ENT); CREATE INDEX ZGEOPLACENAME_ZDA_INDEX ON ZGEOPLACENAME (ZDA); CREATE INDEX ZGEOPLACENAME_ZDE_INDEX ON ZGEOPLACENAME (ZDE); CREATE INDEX ZGEOPLACENAME_ZEN_INDEX ON ZGEOPLACENAME (ZEN); CREATE INDEX ZGEOPLACENAME_ZES_INDEX ON ZGEOPLACENAME (ZES); CREATE INDEX ZGEOPLACENAME_ZFI_INDEX ON ZGEOPLACENAME (ZFI); CREATE INDEX ZGEOPLACENAME_ZFR_INDEX ON ZGEOPLACENAME (ZFR); CREATE INDEX ZGEOPLACENAME_ZIT_INDEX ON ZGEOPLACENAME (ZIT); CREATE INDEX ZGEOPLACENAME_ZJA_INDEX ON ZGEOPLACENAME (ZJA); CREATE INDEX ZGEOPLACENAME_ZKO_INDEX ON ZGEOPLACENAME (ZKO); CREATE INDEX ZGEOPLACENAME_ZNAME_INDEX ON ZGEOPLACENAME (ZNAME); CREATE INDEX ZGEOPLACENAME_ZNL_INDEX ON ZGEOPLACENAME (ZNL); CREATE INDEX ZGEOPLACENAME_ZNO_INDEX ON ZGEOPLACENAME (ZNO); CREATE INDEX ZGEOPLACENAME_ZPL_INDEX ON ZGEOPLACENAME (ZPL); CREATE INDEX ZGEOPLACENAME_ZPT_INDEX ON ZGEOPLACENAME (ZPT); CREATE INDEX ZGEOPLACENAME_ZPT_BR_INDEX ON ZGEOPLACENAME (ZPT_BR); CREATE INDEX ZGEOPLACENAME_ZRU_INDEX ON ZGEOPLACENAME (ZRU); CREATE INDEX ZGEOPLACENAME_ZSV_INDEX ON ZGEOPLACENAME (ZSV); CREATE INDEX ZGEOPLACENAME_ZZH_INDEX ON ZGEOPLACENAME (ZZH); CREATE INDEX ZGEOPLACENAME_ZZH_TW_INDEX ON ZGEOPLACENAME (ZZH_TW); CREATE INDEX ZGEOPLACENAME_ZPLACE_INDEX ON ZGEOPLACENAME (ZPLACE); CREATE INDEX ZGEOPLACENAME_Z_ENT_INDEX ON ZGEOPLACENAME (Z_ENT); CREATE TABLE Z_PRIMARYKEY (Z_ENT INTEGER PRIMARY KEY, Z_NAME VARCHAR, Z_SUPER INTEGER, Z_MAX INTEGER); CREATE TABLE Z_METADATA (Z_VERSION INTEGER PRIMARY KEY, Z_UUID VARCHAR(255), Z_PLIST BLOB); CREATE TABLE Z_MODELCACHE (Z_CONTENT BLOB);
I haven't fired up Mike T's SQLite Database App to try to figure out how to use it to translate a city name to a tzid, but that might be one way to implement the tzid command.
Like it or not, the tzdb identifiers *are* the identifiers used to name and select time zones.
They are the identifiers used to *identify* time zones.
They should not be the only way to *select* time zones; UIs should be offered that allow people to specify a location and have code figure out the time zone.
On Nov 13, 2017, at 7:28 PM, Phake Nick <c933103@gmail.com> wrote:
There are github.com/evansiroky/timezone-boundary-builder that do this.
Where "this" is "shapefiles to let you find the tzdb zone corresponding to a particular longitude and latitude". http://www.geonames.org/export/ provides lists of cities containing: http://download.geonames.org/export/dump/readme.txt geonameid : integer id of record in geonames database name : name of geographical point (utf8) varchar(200) asciiname : name of geographical point in plain ascii characters, varchar(200) alternatenames : alternatenames, comma separated, ascii names automatically transliterated, convenience attribute from alternatename table, varchar(10000) latitude : latitude in decimal degrees (wgs84) longitude : longitude in decimal degrees (wgs84) feature class : see http://www.geonames.org/export/codes.html, char(1) feature code : see http://www.geonames.org/export/codes.html, varchar(10) country code : ISO-3166 2-letter country code, 2 characters cc2 : alternate country codes, comma separated, ISO-3166 2-letter country code, 200 characters admin1 code : fipscode (subject to change to iso code), see exceptions below, see file admin1Codes.txt for display names of this code; varchar(20) admin2 code : code for the second administrative division, a county in the US, see file admin2Codes.txt; varchar(80) admin3 code : code for third level administrative division, varchar(20) admin4 code : code for fourth level administrative division, varchar(20) population : bigint (8 byte int) elevation : in meters, integer dem : digital elevation model, srtm3 or gtopo30, average elevation of 3''x3'' (ca 90mx90m) or 30''x30'' (ca 900mx900m) area in meters, integer. srtm processed by cgiar/ciat. timezone : the iana timezone id (see file timeZone.txt) varchar(40) The latter of those should actually be sufficient, I think, for a system that *doesn't* track your location and update the current time zone in real time. ("In real time" in macOS/iOS/etc. includes a mechanism to update the current tzdb zone *of running processes*, so processes don't have to be restarted while you're in transit or when you get off the plane/train/bus/etc. in a different time zone; I don't think any other UN*Xes do that.)
On 11/13/2017 12:12 PM, Guy Harris wrote:
So every UI that offers a list of tzdb names (or tzdb names slightly tweaked by replacing underscores with blanks, or whatever) as if it were a list of cities is broken.
If your UI is intended *solely* for people who understand what tzdb names are - i.e., they are strings that happen to use city names as a component, but are *not* identifiers for *your* city - then using tzdb names is OK.
If your UI is expected to be used by people who *aren't* familiar with tzdb names, it should not use tzdb names, whether it's a GUI interface or not.
While I agree with this, there is an additional challenge here. If the user selects a name other than the localized form of the TZ name, you really should store that choice. That way, if the location the user chose moves into a newly created zone due to a change in TZ rules, the user will not need to re-select their location. I have no idea how many of the big players (Apple, MS, Google, etc.) do this right. --Ted
On Nov 13, 2017, at 3:09 PM, Ted Cabeen <ted@cabeen.org> wrote:
While I agree with this, there is an additional challenge here. If the user selects a name other than the localized form of the TZ name, you really should store that choice.
You really should store *some indication of the location that can be used to find a tzid*. Whether it's the name of a city is another matter.
That way, if the location the user chose moves into a newly created zone due to a change in TZ rules, the user will not need to re-select their location.
I have no idea how many of the big players (Apple, MS, Google, etc.) do this right.
Apple probably stores either 1) latitude and longitude (given that the default behavior of macOS, iOS, etc. is "pick a tzid zone based on where the machine is") or 2) something that refers to a location in the SQLite database I mentioned in another message.
On Nov 13, 2017, at 6:17 AM, Paul.Koning@dell.com wrote:
No. Tzdb isn't a UI, and doesn't define a UI. UI design is a separate activity, and it's not constrained by tzdb. It would be perfectly valid to offer a UI that has 10k city names in it as a way to set the correct tz for your system.
Yes, that's precisely my point; I'm not making that as a rhetorical statement *against* "It's not a database of cities but of timezones.", meaning "you've said those UIs are invalid, and that's not the right thing to say", I'm making that as a straightforward statement, meaning "those UIs are broken" is a *legitimate* consequence of "It's not a database of cities but of timezones.", and those UIs - such as the Linux Mint UI that provoked the original complaint - should be fixed (doing what Apple has done, for example, would be better).
On 2017-11-11 23:31:28 (+0000), Sébastien Bouchard wrote:
It would be nice if Montreal was included in your database. There are smaller cities that are listed. I am using the latest Linux Mint Mate (18.2) and i had to choose Toronto to get into the right timezone. Montreal is not there.
Please read http://web.cs.ucla.edu/~eggert/tz/theory.html#naming and the archives of this mailing list for many (many!) previous discussions about the names of timezones. Specifically: Montreal (like other parts of Quebec) has been in the same time zone as Toronto since 1970. If you need (often) correct timestamps before 1970, you may be able to use the data in the `backzone` file, though note the comment about correctness in there.
It doesn't matter much to me but there are some people here who will find it strange. Toronto is like... in another country. It's about History and the French people in Canada...
The boundaries used in the tz database are the boundaries of time zones since 1970. While these boundaries are often in the same place as political boundaries this is not always the case. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
To combine two recent topics, if you could get the Quebec government to pass a law delaying the time of switching back to daylight time this coming spring by just one second, then we could get Montreal's zone table back. On a more serious vein, if you could find evidence that Montreal and Toronto's time zones since 1970 were at some time different, or that they implemented daylight saving differently at some point since 1970, that would provide the means for them to be separate zones in the tzdb. I made a vague attempt to find this evidence at one point, but never checked the Toronto Star or Montreal Gazette archives. There could be evidence there. David (a Montrealer in Ontario) On 2017-11-11 20:33, Philip Paeps wrote:
On 2017-11-11 23:31:28 (+0000), Sébastien Bouchard wrote:
It would be nice if Montreal was included in your database. There are smaller cities that are listed. I am using the latest Linux Mint Mate (18.2) and i had to choose Toronto to get into the right timezone. Montreal is not there.
Please read http://web.cs.ucla.edu/~eggert/tz/theory.html#naming and the archives of this mailing list for many (many!) previous discussions about the names of timezones.
Specifically: Montreal (like other parts of Quebec) has been in the same time zone as Toronto since 1970. If you need (often) correct timestamps before 1970, you may be able to use the data in the `backzone` file, though note the comment about correctness in there.
It doesn't matter much to me but there are some people here who will find it strange. Toronto is like... in another country. It's about History and the French people in Canada...
The boundaries used in the tz database are the boundaries of time zones since 1970. While these boundaries are often in the same place as political boundaries this is not always the case.
Philip
--
participants (12)
-
David Patte ₯ -
Deborah Goldsmith -
Guy Harris -
Paul Eggert -
Paul G -
Paul.Koning＠dell.com -
Phake Nick -
Philip Paeps -
Robert Elz -
Sébastien Bouchard -
Ted Cabeen -
Zefram