tzdb timezone names/identifiers and links (was: Add new timezone for Hanoi Capital, Vietnam)
Dear all, as a follow-up to the "Hanoi" thread, I've some questions regarding tzdb policies. As it is a slightly separate / more general point, I'll single that thread out from the initial "Hanoi" discussion. In particular, I'd like to understand the background of the following item (taken from https://data.iana.org/time-zones/theory.html#naming):
There should typically be at least one name for each ISO 3166-1 <https://en.wikipedia.org/wiki/ISO_3166-1> officially assigned two-letter code for an inhabited country or territory.
I initially thought this would be the reason for the "Links" of "Asia/Phnom_Penh" and "Asia/Vientiane" to "Asia/Bangkok". However, latest discussion in the "Hanoi" thread rather attributed these two aliases to backwards compatibility after prior data was moved to the backzone file. I'd assume the quoted "ISO 3166-1"-based policy could make sense for two reasons: a) Congruence of ids and decision-making bodies (i.e., countries/governments): In contrast to data stored using "Asia/Bangkok", systems/data using the "Asia/Phnom_Penh" name/link/alias/id would not need to change/re-configure in case the government of Cambodia decides to deviate from "Asia/Bangkok" at some time b) Politically: Even if tzdb names might not be intended as "names", they do surface from time to time, as with configuring time zones on a machine [1], or by applications just passing through tzdb names. I can somehow understand that this is not fully satisfactory in the Vietnam/Hanoi case right now (see below). While it is neither the intention nor the concern of tzdb to deal with this, one can argue that in practice, there is still clearly a practical impact of tzdb names/ids. So any information on the rationale for the above-quoted rule is appreciated. Also, I see there are recommendations for implementers regarding localization (e.g., reference to Unicode CLDR), but I could not find recommendations concerning the usage of tzdb names/ids/links/aliases - which, in my understanding, will be the String persisted by most applications in the end? If so, setting "Vietnamese" data or systems to an "Asia/Bangkok" tzdb identifier would, to some degree, effectively tie that data to Thai legislation. In case Vietnam would deviate from "Asia/Bangkok" in the future (by either Thai or Vietnamese decision), legacy data might need to be change to an "Asia/Hanoi" identifier. I'd be interested in pointers if this aspect was ever discussed here or is considered relevant at all. Thanks and best, Hans-Joerg ps.: as for the Vietnam case, note that the "displayName()" property in Java shows "Indochina" for most zones under discussion [2] Also Unicode CLDR translations look tricky in this case (http://st.unicode.org/cldr-apps/survey?_=en&x=r_zones) [1] E.g. https://askubuntu.com/questions/323131/setting-timezone-from-terminal/323163 points out the two options of |sudo cp /usr/share/zoneinfo/Asia/Bangkok /etc/localtime| (explicit!) or |tzselect | ..yielding the following dialogue: Please select a country whose clocks agree with yours. 1) Afghanistan 18) Israel 35) Palestine ......... 15) Indonesia 32) Nepal 49) Vietnam 16) Iran 33) Oman 50) Yemen 17) Iraq 34) Pakistan #? 49 Please select one of the following time zone regions. 1) Indochina (most areas) 2) Vietnam (south) ...which looks better, but is also not ideal from a user point-of-view... [2] Java TimeZone.getDisplayName() output for EN/DE/FR locale (Oracle JDK 1.8.0_191): Asia/Bangkok / Indochina Time Asia/Bangkok / Indochina Zeit Asia/Bangkok / Heure d'Indochine Asia/Ho_Chi_Minh / Indochina Time Asia/Ho_Chi_Minh / Indochina Zeit Asia/Ho_Chi_Minh / Heure d'Indochine Asia/Phnom_Penh / Indochina Time Asia/Phnom_Penh / Indochina Zeit Asia/Phnom_Penh / Heure d'Indochine Asia/Saigon / Indochina Time Asia/Saigon / Indochina Zeit Asia/Saigon / Heure d'Indochine Asia/Vientiane / Indochina Time Asia/Vientiane / Indochina Zeit Asia/Vientiane / Heure d'Indochine VST / Indochina Time VST / Indochina Zeit VST / Heure d'Indochine -- audriga GmbH Durlacher Allee 47 76131 Karlsruhe, Germany Tel: +49 (0) 721 17029 316 Fax: +49 (0) 721 17029 3179 www.twitter.com/audriga <http://www.twitter.com/audriga> www.audriga.com <http://www.audriga.com/> Handelsregister: Amtsgericht Mannheim - HRB 713034 Sitz der Gesellschaft: Karlsruhe Geschäftsführer: Dr. Frank Dengler, Dr. Hans-Jörg Happel USt-ID: DE 279724142
Hans-Joerg Happel wrote:
So any information on the rationale for the above-quoted rule is appreciated.
When I introduced locations as tzdb identifiers long ago, I naively put in one Zone or Link per country. Some users got accustomed to the idea that Zone and/or Link status was akin to political recognition of countries or their boundaries (is Kosovo a country? is Jerusalem part of Palestine? that sort of thing) and so I eventually realized my mistake: the identifiers are now supposed to be single locations, decoupled from countries or national regions. At one point I attempted to simplify the database by coalescing regions that crossed country boundaries, since there's no longer any need to conflate the two. Unfortunately this flustered some users who thought this meant disrepect to particular countries (which was not the intent). After some back and forth we ended up with the current wording, which I'm not happy with, as the current rules are still too political and we still end up with "There should be an entry for Hanoi/Beijing/etc.!" discussions. If this continues to be a sore spot, I'm inclined to adjust the rules so that there need not at least one Link or Zone per country. This should help simplify future maintenance if, say, the US splits into multiple countries (and stuff like that does happen).
I see there are recommendations for implementers regarding localization (e.g., reference to Unicode CLDR), but I could not find recommendations concerning the usage of tzdb names/ids/links/aliases - which, in my understanding, will be the String persisted by most applications in the end?
Although the "Names of timezones" section in <https://data.iana.org/time-zones/theory.html> talks about this, it sounds like you think something is missing. I'm not sure what sort of recommendations you're thinking about, though. Perhaps you could suggest a specific wording change to that section?
setting "Vietnamese" data or systems to an "Asia/Bangkok" tzdb identifier would, to some degree, effectively tie that data to Thai legislation.
No, it ties that data to our best guess of what northern Vietnam etc. will do. It does not tie the data to any legislation, just as setting "Moroccan" data or systems to "Africa/Casablanca" ties that data to our best guess of what Morocco will do, regardless of existing legislation. In both cases our guesses may well be wrong and if so users will need to deal with the wrong guesses, which is just part of life when predicting the future. If we started letting political considerations affect how we record our guesses, that would lead to more controversy and more database churn and I'd rather not go that direction.
On Feb 19, 2019, at 8:34 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
Hans-Joerg Happel wrote:
setting "Vietnamese" data or systems to an "Asia/Bangkok" tzdb identifier would, to some degree, effectively tie that data to Thai legislation.
No, it ties that data to our best guess of what northern Vietnam etc. will do.
...and if they do something that doesn't match our guess, so that it differs from what's done in Thailand, we'd probably end up pulling Asia/Hanoi out of the backzone file, put it into the asia file, and changing it as appropriate. For example, if Vietnam were to introduce summer time when Thailand doesn't do so, or when Thailand does so with different rules, we'd probably: pull Asia/Hanoi out of backzone and put it into asia; add summer time rules for Vietnam; change both Asia/Hanoi and Asia/Ho_Chi_Minh to refer to those rules; (and, in the latter case, add summer time rules as appropriate for Thailand and modify Asia/Bangkok to use them). (Now *that's* the kind of government action that would get us to introduce Asia/Hanoi as a non-backzone tzdb region. :-))
On Tue, 19 Feb 2019 at 16:35, Paul Eggert <eggert@cs.ucla.edu> wrote:
If this continues to be a sore spot, I'm inclined to adjust the rules so that there need not at least one Link or Zone per country. This should help simplify future maintenance if, say, the US splits into multiple countries (and stuff like that does happen).
This will create more problems, not less. Time zones are by nature the product of politics, so issues around countries/territories simply can't be avoided. The rules already link to ISO 3166-1 code, thus the key part of the problem is already sidestepped. Hanoi is an edge case, because if the current rules were applied as of 1970, Hanoi would have to be an active zone.
setting "Vietnamese" data or systems to an "Asia/Bangkok" tzdb identifier would, to some degree, effectively tie that data to Thai legislation.
Vietnamese systems looking to future dates should be set to Asia/Ho_Chi_Minh, shouldn't they? Stephen
On 19.02.19 20:00, Stephen Colebourne wrote:
On Tue, 19 Feb 2019 at 16:35, Paul Eggert <eggert@cs.ucla.edu> wrote:
If this continues to be a sore spot, I'm inclined to adjust the rules so that there need not at least one Link or Zone per country. This should help simplify future maintenance if, say, the US splits into multiple countries (and stuff like that does happen). This will create more problems, not less. Time zones are by nature the product of politics, so issues around countries/territories simply can't be avoided. The rules already link to ISO 3166-1 code, thus the key part of the problem is already sidestepped.
Hanoi is an edge case, because if the current rules were applied as of 1970, Hanoi would have to be an active zone.
setting "Vietnamese" data or systems to an "Asia/Bangkok" tzdb identifier would, to some degree, effectively tie that data to Thai legislation. Vietnamese systems looking to future dates should be set to Asia/Ho_Chi_Minh, shouldn't they?
I tend to agree with you on this. However, your rationale for this is the result of a >50 mail discussion and not easily to grasp for any tzdb consumer based on the way tzdb is build right now. Second, what about the case of a Linux laptop located in Hanoi configured to use "Asia/Ho_Chi_Minh". Some sort of calculation might still go wrong then. Clearly a made up example, but isn't time zone math also about unintended consequences? Best, Hans-Joerg
Stephen
-- audriga GmbH Durlacher Allee 47 76131 Karlsruhe, Germany Tel: +49 (0) 721 17029 316 Fax: +49 (0) 721 17029 3179 www.twitter.com/audriga <http://www.twitter.com/audriga> www.audriga.com <http://www.audriga.com/> Handelsregister: Amtsgericht Mannheim - HRB 713034 Sitz der Gesellschaft: Karlsruhe Geschäftsführer: Dr. Frank Dengler, Dr. Hans-Jörg Happel USt-ID: DE 279724142
On Feb 19, 2019, at 11:23 AM, Hans-Joerg Happel <happel@audriga.com> wrote:
Second, what about the case of a Linux laptop located in Hanoi configured to use "Asia/Ho_Chi_Minh". Some sort of calculation might still go wrong then.
...such as converting a POSIX-form date-and-time value from 1972 to local time; it'll use UTC+8 rather than UTC+7, but the latter would be appropriate for local (Hanoi) time in 1972.
On Feb 19, 2019, at 11:00 AM, Stephen Colebourne <scolebourne@joda.org> wrote:
On Tue, 19 Feb 2019 at 16:35, Paul Eggert <eggert@cs.ucla.edu> wrote:
setting "Vietnamese" data or systems to an "Asia/Bangkok" tzdb identifier would, to some degree, effectively tie that data to Thai legislation.
Vietnamese systems looking to future dates should be set to Asia/Ho_Chi_Minh, shouldn't they?
Currently, they agree, so it doesn't matter whether, for current dates/times, you use Asia/Bangkok or Asia/Ho_Chi_Minh. In the past, they didn't agree, so, to correctly convert dates/times between 1970 and reunification in 1975, you should use Asia/Bangkok for North Vietnam and Asia/Ho_Chi_Minh for South Vietnam. If Vietnam changes in such a fashion so that future dates will not properly be handled by Asia/Bangkok, they won't properly be handled by the current Asia/Ho_Chi_Minh. In that case, we should probably bring Asia/Hanoi into asia from backzone, and update both Asia/Hanoi and Asia/Ho_Chi_Minh to the new rules, so that locations in what was North Vietnam would use Asia/Hanoi and locations in what was South Vietnam would use Asia/Ho_Chi_Minh.
Dear Paul, thanks for the elaboration - further comments inline On 19.02.19 17:34, Paul Eggert wrote:
Hans-Joerg Happel wrote:
So any information on the rationale for the above-quoted rule is appreciated.
When I introduced locations as tzdb identifiers long ago, I naively put in one Zone or Link per country. Some users got accustomed to the idea that Zone and/or Link status was akin to political recognition of countries or their boundaries (is Kosovo a country? is Jerusalem part of Palestine? that sort of thing) and so I eventually realized my mistake: the identifiers are now supposed to be single locations, decoupled from countries or national regions.
At one point I attempted to simplify the database by coalescing regions that crossed country boundaries, since there's no longer any need to conflate the two. Unfortunately this flustered some users who thought this meant disrepect to particular countries (which was not the intent). After some back and forth we ended up with the current wording, which I'm not happy with, as the current rules are still too political and we still end up with "There should be an entry for Hanoi/Beijing/etc.!" discussions.
If this continues to be a sore spot, I'm inclined to adjust the rules so that there need not at least one Link or Zone per country. This should help simplify future maintenance if, say, the US splits into multiple countries (and stuff like that does happen).
I'd see two different kinds of "maintenance" here: * Maintenance of tzdb (which you are referring to) * Maintenance of systems/data by people using tzdb (directly or indirectly) So in your example - if say, Washington (the federal state) would become a separate country, you argue to keep maintenance of tzdb low by sticking to "America/Los_Angeles", whereas one could argue for a link from "America/Seattle" (or the like) according to the current ISO 3166-1 rule in [1]. On the other hand, if Washington users could make use of such an "America/Seattle" alias, that could reduce maintenance effort in the event of of the new country of Washington deciding to deviate from "America/Los_Angeles" rules (which, as you say is stuff that will happen one or the other way). To be clear: I perfectly understand that the first kind of "maintenance" is the main concern of the tzdb community. However, I am trying to make a point that tzdb design decisions may have further kind of impact (second aspect of maintenance), and I wonder to what degree these concerns are shared. Another point I made was that in my experience some applications "misuse" tzdb identifiers as actual time zone names shown to users. While I agree it would be better to solve this on a more general level such as geo-location<=>timezone mappings (and I know efforts in that direction exist) I'd still argue that one won't get around that "misuse" practice anytime soon. It's a matter of philosophy if that counts as an argument for the ISO 3166-1 rule case. Disclosure: I am involved in CalConnect's efforts to advise governments and practitioners on how to tackle time zone issues. Therefore I am trying to get a better understanding of how things work and appreciate your feedback, even if it might slightly go beyond the scope of pure tzdb maintenance.
I see there are recommendations for implementers regarding localization (e.g., reference to Unicode CLDR), but I could not find recommendations concerning the usage of tzdb names/ids/links/aliases - which, in my understanding, will be the String persisted by most applications in the end?
Although the "Names of timezones" section in <https://data.iana.org/time-zones/theory.html> talks about this, it sounds like you think something is missing. I'm not sure what sort of recommendations you're thinking about, though. Perhaps you could suggest a specific wording change to that section?
I'd perhaps first suggest to talk about "Identifiers of timezones" instead of "Names of timezones". The distinction may sound picky, but I've the impression some discussions (such as the "Hanoi" one) circle around the misunderstanding of "Asia/Bangkok" being some sort of semi-official "name" while it is supposed to be (as you pointed out above), A second suggestion would be a short note that it is these identifiers which would be typically stored in database / system configuration / appointment in order to denote the time zone of a "thing" and that software will typically pick up the additional rule data in tzdb in order to compute meaningful things based on these identifiers. This is sort of implicit to the given text, but might be pointed out more explicitly. Note that my perspective here is rather from an end user / developer point of view and I acknowledge that this is not the main audience of tzdb content. However I'd argue that end users / developers might find some clarification on this useful when considering their use of identifiers which ultimately stem from and are maintained by tzdb. I don't know the change policy of theory.html, but if there's some agreement that I have a point here, I'd be happy to propose more particular wording changes.
setting "Vietnamese" data or systems to an "Asia/Bangkok" tzdb identifier would, to some degree, effectively tie that data to Thai legislation.
No, it ties that data to our best guess of what northern Vietnam etc. will do. It does not tie the data to any legislation, just as setting "Moroccan" data or systems to "Africa/Casablanca" ties that data to our best guess of what Morocco will do, regardless of existing legislation. In both cases our guesses may well be wrong and if so users will need to deal with the wrong guesses, which is just part of life when predicting the future. If we started letting political considerations affect how we record our guesses, that would lead to more controversy and more database churn and I'd rather not go that direction.
My assumption (also in the US/Washington case above) is, that it is (in most cases) countries which do cast decisions about time zone rules. Therefore, both Vietnam and Thailand seem to be free to change time zone rules at any time soon. Assuming two databases, one with "Vietnamese data" on an office server in Hanoi, one with "Thai data" on an office server in Bangkok, both databases would currently use "Asia/Bangkok" as an identifier. So in case the Thai government decides to change time zone rules for Thailand (and Vietnam would not follow), if I am not wrong, this would most probably require tzdb to introduce an "Asia/Hanoi" identifier to accommodate for this new situation. However, people maintaining the server with "Vietnamese data" might then need to convert that data from using "Asia/Bangkok" to "Asia/Hanoi" (my example may sound a little simple or arbitrary, but I also want to understand if you share the idea that this may be a point). So given that example I'd argue that a Thai government could indeed influence Vietnamese data. Coming back to the "Hanoi" thread, I also think this might be a valid concern of Vietnamese people while being "forced" to use an "Asia/Bangkok" identifier. However, I also see your point about additional controversy. On the other hand I think the existing technique of "Links" seems to be a relatively simple way of resolving some of the points I made above, and that the current "Asia/Phnom_Penh" has its value with respect to this. Best, Hans-Joerg [1] https://data.iana.org/time-zones/theory.html#naming -- audriga GmbH Durlacher Allee 47 76131 Karlsruhe, Germany Tel: +49 (0) 721 17029 316 Fax: +49 (0) 721 17029 3179 www.twitter.com/audriga <http://www.twitter.com/audriga> www.audriga.com <http://www.audriga.com/> Handelsregister: Amtsgericht Mannheim - HRB 713034 Sitz der Gesellschaft: Karlsruhe Geschäftsführer: Dr. Frank Dengler, Dr. Hans-Jörg Happel USt-ID: DE 279724142
On Tue 2019-02-19T20:14:14+0100 Hans-Joerg Happel hath writ:
Disclosure: I am involved in CalConnect's efforts to advise governments and practitioners on how to tackle time zone issues. Therefore I am trying to get a better understanding of how things work and appreciate your feedback, even if it might slightly go beyond the scope of pure tzdb maintenance.
Communicating the scope and aim is much effort. The scope of IANA tzdb is, in short, to provide a way for POSIX-like systems to convert between internal system clock time_t values and local civil time in a way where a single choice is valid for all history since 1970. This is reasonably well documented. The scopes of CLDR and the ICU, IATA SSIM, Microsoft Windows, Apple, Android, the CalConnect ISO effort, etc. are not so clearly documented. It is clear that they do not try to solve the same problems, and not clear how they set the boundaries of their scope. -- 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
On 2019-02-19 19:35, Steve Allen wrote:
The scope of IANA tzdb is, in short, to provide a way for POSIX-like systems to convert between internal system clock time_t values and local civil time in a way where a single choice is valid for all history since 1970. This is reasonably well documented.
Regardless how well tzdb is documented, one cannot say that tzdb data is very systematic. Compare the case of Asia/Hanoi with that of Europe/Busingen. Europe/Busingen was introduced into tzdb on 2013-02-27; it differs from Europe/Berlin since 1970, but it agrees with Europe/Zurich and was linked to it ever since. Only five years later, Asia/Hanoi was added to backzone; it differs from Asia/Ho_Chi_Minh since 1970, but agrees with Asia/Bangkok since 1955. Why was Europe/Busingen not added to backzone as Asia/Hanoi was? Its history is known very precisely. Why was Asia/Hanoi not added as a link as Europe/Busingen was? It may well be that some changes in the theory file can be construed to explain the discrepancy, but I think that database data should reflect the current design principles, not their history. I may be a sloppy reader, but I do see what the theory.html file says about the two questions above. Michael Deckers.
On Tue, 19 Feb 2019 at 15:27, Guy Harris <guy@alum.mit.edu> wrote:
Maybe this is *another* case where "some applications "misuse" tzdb identifiers" and where it might "be better to solve this on a more general level such as geo-location<=>timezone mappings", e.g. a meeting date shouldn't be tagged with {date/time, tzdb identifier} but with {date/time, geographic coordinates}.
Unfortunately, there seems to be a widespread (mistaken) belief that geographic coordinates are sufficient for deriving the proper tz identifier in all, or even most cases. To say nothing of disputed, fluid, and overlapping territories, folks in actual border communities make all sorts of *de facto* arrangements as well. There is a very good reason this project doesn't attempt to define boundaries, and it's not just an issue of scope, it's an issue of practicality and tractability. On Tue, 19 Feb 2019 at 16:10, Michael H Deckers via tz <tz@iana.org> wrote:
Why was Europe/Busingen not added to backzone as Asia/Hanoi was? Its history is known very precisely. Why was Asia/Hanoi not added as a link as Europe/Busingen was?
Frankly, it seems it was because when Asia/Hanoi was added to backzone (in 2014, not "five years later" as you write), the opportunity was taken then and there to change/redefine the rules to avoid scope creep. Which is all well and good from a project maintenance standpoint, though I can totally see why that can seem unfair from a human standpoint. Had we operated under the rules that existed just before the Hanoi history was first presented to us, Asia/Hanoi would have had to go into the main distribution. The zone-country rules were then deliberately changed to avoid this (see Laos and Cambodia being coalesced, along with northern Vietnam, into Asia/Bangkok). The 2014 submission for Asia/Hanoi was made in good faith at the time, and while that certainly does not *require* that a new zone be created, it does feel a little off to effectively have that potential outcome removed retroactively. Simply put, Hanoi seems to be the major exception here because it was *the* zone for which its need was being assessed right at the time when the rules were being changed. -- Tim Parenti
On 2019-02-19 21:22, Tim Parenti wrote:
Frankly, it seems it was because when Asia/Hanoi was added to backzone (in 2014, not "five years later" as you write), the opportunity was taken then and there to change/redefine the rules to avoid scope creep. Which is all well and good from a project maintenance standpoint, though I can totally see why that can seem unfair from a human standpoint.
So, before the inclusion of backzone/Asia/Hanoi on 2014-10-22, a little "scope creep" was still allowed on 2013-09-20 for America/Curacao (which agrees with America/Port_of_Spain since 1970) but not for America/Aruba (which also does)? I understand that tzdb is a non-commercial project -- but this is just one more reason to establish simple and stable guidelines that are easily understood, rather than to hunt for elusive goals. Michael Deckers.
So, since it's pretty clear that the "There should typically be at least one name for each ISO 3166-1 officially assigned two-letter code for an inhabited country or territory" guideline has been, if not abandoned entirely, at least significantly de-prioritized, perhaps theory.html needs an update indicating that, yes, this *used* to be considered more important, but is not any longer (perhaps going a bit into the rationale), and that we don't intend to create new zones anymore if that's the only justification. -- Tim Parenti On Tue, 19 Feb 2019 at 17:25, Michael H Deckers < michael.h.deckers@googlemail.com> wrote:
On 2019-02-19 21:22, Tim Parenti wrote:
Frankly, it seems it was because when Asia/Hanoi was added to backzone (in 2014, not "five years later" as you write), the opportunity was taken then and there to change/redefine the rules to avoid scope creep. Which is all well and good from a project maintenance standpoint, though I can totally see why that can seem unfair from a human standpoint.
So, before the inclusion of backzone/Asia/Hanoi on 2014-10-22, a little "scope creep" was still allowed on 2013-09-20 for America/Curacao (which agrees with America/Port_of_Spain since 1970) but not for America/Aruba (which also does)?
I understand that tzdb is a non-commercial project -- but this is just one more reason to establish simple and stable guidelines that are easily understood, rather than to hunt for elusive goals.
Michael Deckers.
On 2/19/19 2:31 PM, Tim Parenti wrote:
So, since it's pretty clear that the "There should typically be at least one name for each ISO 3166-1 officially assigned two-letter code for an inhabited country or territory" guideline has been, if not abandoned entirely, at least significantly de-prioritized, perhaps theory.html needs an update indicating that, yes, this /used/ to be considered more important, but is not any longer (perhaps going a bit into the rationale), and that we don't intend to create new zones anymore if that's the only justification.
Sounds good to me; proposed patch attached.
I would suggest stating an explicit non-goal of ">1 zone per country code" up front. Burying it in the "old versions" section isn't enough. The reason is that people think of zones and countries, and are likely to assume that this rule exists. So telling them early on, in plain words "no we're not doing that" may help reduce the noise somewhat. paul
On Feb 19, 2019, at 6:17 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 2/19/19 2:31 PM, Tim Parenti wrote:
So, since it's pretty clear that the "There should typically be at least one name for each ISO 3166-1 officially assigned two-letter code for an inhabited country or territory" guideline has been, if not abandoned entirely, at least significantly de-prioritized, perhaps theory.html needs an update indicating that, yes, this /used/ to be considered more important, but is not any longer (perhaps going a bit into the rationale), and that we don't intend to create new zones anymore if that's the only justification.
Sounds good to me; proposed patch attached.
<0001-Deprecate-the-ISO-3166-1-guideline.patch>
I strongly oppose this patch. At least one zone per ISO 3166-1 is a vital part of this project and an entirely sensible rule. It is what users expect the project to provide. TZDB identifiers are used incredibly widely, and are seen on many public-facing systems. I understand that is not seen as desirable by some here, but it is the truth. When a country splits, it is usually for painful reasons. The idea that the half of the country should be forced to use the old identifier simply isn't tenable. Stephen On Tue, 19 Feb 2019 at 23:17, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 2/19/19 2:31 PM, Tim Parenti wrote:
So, since it's pretty clear that the "There should typically be at least one name for each ISO 3166-1 officially assigned two-letter code for an inhabited country or territory" guideline has been, if not abandoned entirely, at least significantly de-prioritized, perhaps theory.html needs an update indicating that, yes, this /used/ to be considered more important, but is not any longer (perhaps going a bit into the rationale), and that we don't intend to create new zones anymore if that's the only justification.
Sounds good to me; proposed patch attached.
This is basically what I was about when asking for the "scope" of tzdb, and might end up in a similar discussion concerning timezone ids just like the Wikipedia's inclusionism/exclusionism debate. Standpoints: a) (Exclusionist) Timezone ids should be kept at a minimum level required to model tz rules appropriately b) (Inclusionist) There should be at least one timezone id for each ISO 3166-1 TLC ...and as the "Hanoi" case would not be covered by (b) the even extended inclusionist approach would rather be something like: c) (Inclusionist+) There should be at least one timezone id for each "timezone" (in the sense of tzdb's consistent-since-1970 definition) for each ISO 3166-1 TLC I see the point of simply sticking to (a). However, not all all users of tzdb will grasp this, and so there will always be considerable "misuse" of timezone ids and discussions such as the recent "Hanoi" thread. However it looks like there is no real solution to this, as either choice has its subtleties. So sticking to the status quo might be the best to do for now. While I think I understand the perspective of people who are arguing to focus on core tzdb maintenance, I'd however encourage tzdb "users" (which I guess are also represented on this list) to speak up regarding challenges they observe. I think such discussion might be worthwhile 1) to raise sensitivity for tzdb usage challenges in this community and 2) to better understand pain points in the usage of time zones / time zone identifiers in general. For instance, has anybody ever seen an approach such as advised in the note suggested by Paul [1], or are we actually all sticking to just storing tzdb identifiers? Thanks and best, Hans-Joerg [1] Timezone boundaries are not part of the stable interface. For example, even though the <samp>Asia/Bangkok</samp> timezone currently includes Chang Mai, Hanoi, and Phnom Penh, this is not part of the stable interface and the timezone can split at any time. If a calendar application records a future event in some location other than Bangkok by putting "<samp>Asia/Bangkok</samp>" in the event's record, the application should be robust in the presence of timezone splits between now and the future time. On 20.02.19 13:37, Stephen Colebourne wrote:
I strongly oppose this patch. At least one zone per ISO 3166-1 is a vital part of this project and an entirely sensible rule. It is what users expect the project to provide.
TZDB identifiers are used incredibly widely, and are seen on many public-facing systems. I understand that is not seen as desirable by some here, but it is the truth. When a country splits, it is usually for painful reasons. The idea that the half of the country should be forced to use the old identifier simply isn't tenable.
Stephen
On Tue, 19 Feb 2019 at 23:17, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 2/19/19 2:31 PM, Tim Parenti wrote:
So, since it's pretty clear that the "There should typically be at least one name for each ISO 3166-1 officially assigned two-letter code for an inhabited country or territory" guideline has been, if not abandoned entirely, at least significantly de-prioritized, perhaps theory.html needs an update indicating that, yes, this /used/ to be considered more important, but is not any longer (perhaps going a bit into the rationale), and that we don't intend to create new zones anymore if that's the only justification. Sounds good to me; proposed patch attached.
-- audriga GmbH Durlacher Allee 47 76131 Karlsruhe, Germany Tel: +49 (0) 721 17029 316 Fax: +49 (0) 721 17029 3179 www.twitter.com/audriga <http://www.twitter.com/audriga> www.audriga.com <http://www.audriga.com/> Handelsregister: Amtsgericht Mannheim - HRB 713034 Sitz der Gesellschaft: Karlsruhe Geschäftsführer: Dr. Frank Dengler, Dr. Hans-Jörg Happel USt-ID: DE 279724142
I did a short check on the ISO 3166-1-rule compliance of the current release. It seems that most cases, in which zone1970.tab lists multiple countries on the left hand side (tied to one timezone id), there do exist corresponding "Link" entries. The "VN" in "TH,KH,LA,VN" is the only case I found so far, in which there is no "Link" backing this with a separate identifier (I know the HCM/Hanoi case is special; this is just an observation). Example: [zone1970.tab] CZ,SK +5005+01426 Europe/Prague [europe] # Slovakia Link Europe/Prague Europe/Bratislava Is anybody aware of how upstream software based on tzdb is typically dealing with "Links"? It seems, Java does list time zone ids stemming from "links", while "tzselect" on my Ubuntu machine does not seem to use them - at least not in the interactive configuration [1] (Side note: the "Link" syntax does not seem to be explained yet in https://data.iana.org/time-zones/tz-how-to.html) Further observations: The "zone.tab" file actually uses the "Link" aliases, while "zone1970.tab" does not: [zone.tab] CZ +5005+01426 Europe/Prague SK +4809+01707 Europe/Bratislava vs. [zone1970.tab] CZ,SK +5005+01426 Europe/Prague ...so one will yield different results depending on which .tab file an application uses. Also, "zone.tab" only offers "Asia/Ho_Chi_Minh" for VN (missing out "Asia/Bangkok", which I guess according to tzdb guidelines should be there?): VN +1045+10640 Asia/Ho_Chi_Minh (not sure if the latter was already covered in the Hanoi thread) Best, Hans-Joerg [1] tzselect output on Ubuntu after choosing the respective country: The following information has been given: Slovenia Therefore TZ='Europe/Belgrade' will be used. The following information has been given: Oman Therefore TZ='Asia/Dubai' will be used. The following information has been given: Cambodia Indochina (most areas) Therefore TZ='Asia/Bangkok' will be used. On 20.02.19 17:40, Hans-Joerg Happel wrote:
This is basically what I was about when asking for the "scope" of tzdb, and might end up in a similar discussion concerning timezone ids just like the Wikipedia's inclusionism/exclusionism debate.
Standpoints:
a) (Exclusionist) Timezone ids should be kept at a minimum level required to model tz rules appropriately b) (Inclusionist) There should be at least one timezone id for each ISO 3166-1 TLC ...and as the "Hanoi" case would not be covered by (b) the even extended inclusionist approach would rather be something like: c) (Inclusionist+) There should be at least one timezone id for each "timezone" (in the sense of tzdb's consistent-since-1970 definition) for each ISO 3166-1 TLC
I see the point of simply sticking to (a). However, not all all users of tzdb will grasp this, and so there will always be considerable "misuse" of timezone ids and discussions such as the recent "Hanoi" thread.
However it looks like there is no real solution to this, as either choice has its subtleties. So sticking to the status quo might be the best to do for now.
While I think I understand the perspective of people who are arguing to focus on core tzdb maintenance, I'd however encourage tzdb "users" (which I guess are also represented on this list) to speak up regarding challenges they observe.
I think such discussion might be worthwhile 1) to raise sensitivity for tzdb usage challenges in this community and 2) to better understand pain points in the usage of time zones / time zone identifiers in general.
For instance, has anybody ever seen an approach such as advised in the note suggested by Paul [1], or are we actually all sticking to just storing tzdb identifiers?
Thanks and best, Hans-Joerg
[1] Timezone boundaries are not part of the stable interface. For example, even though the <samp>Asia/Bangkok</samp> timezone currently includes Chang Mai, Hanoi, and Phnom Penh, this is not part of the stable interface and the timezone can split at any time. If a calendar application records a future event in some location other than Bangkok by putting "<samp>Asia/Bangkok</samp>" in the event's record, the application should be robust in the presence of timezone splits between now and the future time. On 20.02.19 13:37, Stephen Colebourne wrote:
I strongly oppose this patch. At least one zone per ISO 3166-1 is a vital part of this project and an entirely sensible rule. It is what users expect the project to provide.
TZDB identifiers are used incredibly widely, and are seen on many public-facing systems. I understand that is not seen as desirable by some here, but it is the truth. When a country splits, it is usually for painful reasons. The idea that the half of the country should be forced to use the old identifier simply isn't tenable.
Stephen
On Tue, 19 Feb 2019 at 23:17, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 2/19/19 2:31 PM, Tim Parenti wrote:
So, since it's pretty clear that the "There should typically be at least one name for each ISO 3166-1 officially assigned two-letter code for an inhabited country or territory" guideline has been, if not abandoned entirely, at least significantly de-prioritized, perhaps theory.html needs an update indicating that, yes, this /used/ to be considered more important, but is not any longer (perhaps going a bit into the rationale), and that we don't intend to create new zones anymore if that's the only justification. Sounds good to me; proposed patch attached.
-- audriga GmbH Durlacher Allee 47 76131 Karlsruhe, Germany Tel: +49 (0) 721 17029 316 Fax: +49 (0) 721 17029 3179
www.twitter.com/audriga <http://www.twitter.com/audriga> www.audriga.com <http://www.audriga.com/>
Handelsregister: Amtsgericht Mannheim - HRB 713034 Sitz der Gesellschaft: Karlsruhe Geschäftsführer: Dr. Frank Dengler, Dr. Hans-Jörg Happel USt-ID: DE 279724142
On 2/20/19 9:21 AM, Hans-Joerg Happel wrote:
Is anybody aware of how upstream software based on tzdb is typically dealing with "Links"? It seems, Java does list time zone ids stemming from "links", while "tzselect" on my Ubuntu machine does not seem to use them - at least not in the interactive configuration [1]
Ubuntu is probably using tzselect from a recent tzdb distribution. tzselect takes its list of names from zone1970.tab, whose names currently consists of the Zone names in the following files: africa antarctica asia australasia europe northamerica southamerica except for the following Zone names, which are present in the above files only for backwards compatibility with long-obsolete Unix systems: CET CST6CDT EET EST EST5EDT HST MET MST MST7MDT PST8PDT WET zone1970.tab does not list Link names, as there's no technical need to use a Link name except for backward-compatibility reasons. It might make sense at some point to move the CET etc. entries and the Link lines to some other file to make it easier for distributions to exclude these entries if they don't have backward-compatibility issues.
On 2/20/19 4:37 AM, Stephen Colebourne wrote:
When a country splits, it is usually for painful reasons. The idea that the half of the country should be forced to use the old identifier simply isn't tenable.
And yet (as Hans-Joerg Happel mentions) Ubuntu and other systems are doing just that in countries that have split up extraordinarily painfully, as shown in the example interaction below. So it seems this approach is tenable enough, at least for the technical interfaces that timezone names are designed for. Although these names may be inappropriate for nontechnical users, they're explicitly not designed for that, and attempting to support them in applications they're not designed for will likely cause everybody more trouble than it's worth. It's not clear that we should continue to cater to such attempts by splitting or renaming timezones for purely political reasons. ---- $ tzselect Please identify a location so that time zone rules can be set correctly. Please select a continent, ocean, "coord", or "TZ". 1) Africa 2) Americas 3) Antarctica 4) Asia 5) Atlantic Ocean 6) Australia 7) Europe 8) Indian Ocean 9) Pacific Ocean 10) coord - I want to use geographical coordinates. 11) TZ - I want to specify the timezone using the Posix TZ format. #? 7 Please select a country whose clocks agree with yours. 1) Albania 18) Guernsey 35) Poland 2) Andorra 19) Hungary 36) Portugal 3) Austria 20) Ireland 37) Romania 4) Belarus 21) Isle of Man 38) Russia 5) Belgium 22) Italy 39) San Marino 6) Bosnia & Herzegovina 23) Jersey 40) Serbia 7) Britain (UK) 24) Latvia 41) Slovakia 8) Bulgaria 25) Liechtenstein 42) Slovenia 9) Croatia 26) Lithuania 43) Spain 10) Czech Republic 27) Luxembourg 44) Svalbard & Jan Mayen 11) Denmark 28) Malta 45) Sweden 12) Estonia 29) Moldova 46) Switzerland 13) Finland 30) Monaco 47) Turkey 14) France 31) Montenegro 48) Ukraine 15) Germany 32) Netherlands 49) Vatican City 16) Gibraltar 33) North Macedonia 50) Åland Islands 17) Greece 34) Norway #? 6 The following information has been given: Bosnia & Herzegovina Therefore TZ='Europe/Belgrade' will be used. Selected time is now: Thu Feb 21 01:00:44 CET 2019. Universal Time is now: Thu Feb 21 00:00:44 UTC 2019. Is the above information OK? 1) Yes 2) No #? 1 You can make this change permanent for yourself by appending the line TZ='Europe/Belgrade'; export TZ to the file '.profile' in your home directory; then log out and log in again. Here is that TZ value again, this time on standard output so that you can use the ./tzselect command in shell scripts: Europe/Belgrade
Paul Eggert <eggert@cs.ucla.edu> wrote on Wed, 20 Feb 2019 at 04:09:42 PM -0800 in <2ffc250d-5eaa-5260-cef1-ab828460bf9e@cs.ucla.edu>:
So it seems this approach is tenable enough, at least for the technical interfaces that timezone names are designed for. Although these names may be inappropriate for nontechnical users, they're explicitly not designed for that, and attempting to support them in applications they're not designed for will likely cause everybody more trouble than it's worth.
I think it's that last point that isn't well-supported in this argument, and that we go around and around on. But we shouldn't pretend that there's agreement on that point, or that the answer is obvious, or that we have a good way to weigh the costs if we do not. It's clear where Paul's preference is, but it's not really clear if there is some absolute rubric of pain, trouble, and frustration that we should be evaluating this on. I tend to think a clear allowance of one zone per country code would reduce the amount of pain and discussion on this mailing list, as well as in the real world outside the tz project, and we really ought to consider it. Sometimes it feels like we are fighting over a line in the sand drawn arbitrarily some time ago without having thought it through, and that is particularly hard to defend. --jhawk@mit.edu John Hawkinson
On Thu, 21 Feb 2019 at 00:09, Paul Eggert <eggert@cs.ucla.edu> wrote:
Although these names may be inappropriate for nontechnical users, they're explicitly not designed for that, and attempting to support them in applications they're not designed for will likely cause everybody more trouble than it's worth. It's not clear that we should continue to cater to such attempts by splitting or renaming timezones for purely political reasons.
Its absolutely clear to me that TZDB should provide such identifiers. Java exposes all Link entries as first class citizens precisely for this reason. It really doesn't matter what TZDB maintainers think the IDs should be used for in some perfect theoretical view. What actually matters is how they are used in real life by real end users. The logical result of this course of action is that downstream projects/users will have to create their own identifiers. Do you want that? Going "la la la" and trying to pretend that countries don't exist is IMO ridiculous and will cause maintainers far more pain. Stephen
On 2/19/19 11:14 AM, Hans-Joerg Happel wrote:
I'd perhaps first suggest to talk about "Identifiers of timezones" instead of "Names of timezones".
We can emphasize the "identifier" stuff a bit more, as in the attached proposed patch. I'm leery of globally replacing "name" with "identifier" though, as "name" is shorter and makes the text easier to follow.
A second suggestion would be a short note that it is these identifiers which would be typically stored in database / system configuration / appointment in order to denote the time zone of a "thing" and that software will typically pick up the additional rule data in tzdb in order to compute meaningful things based on these identifiers. This is sort of implicit to the given text, but might be pointed out more explicitly.
While this may be common practice, I'm not sure we should recommend it as it's fragile in the presence of timezone splits. The proposed patch attempts to add a warning along these lines.
On Feb 19, 2019, at 11:59 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
On 2/19/19 11:14 AM, Hans-Joerg Happel wrote:
A second suggestion would be a short note that it is these identifiers which would be typically stored in database / system configuration / appointment in order to denote the time zone of a "thing" and that software will typically pick up the additional rule data in tzdb in order to compute meaningful things based on these identifiers. This is sort of implicit to the given text, but might be pointed out more explicitly.
While this may be common practice, I'm not sure we should recommend it as it's fragile in the presence of timezone splits.
I.e., if the "thing" is a *past* event/appointment/something else with a time and date, it's safe to associate a tzdb id with it, but if it's a *future* event/appointment/etc., or a *location*, the appropriate tzdb id is subject to change in the future.
On 19.02.19 20:59, Paul Eggert wrote:
On 2/19/19 11:14 AM, Hans-Joerg Happel wrote:
I'd perhaps first suggest to talk about "Identifiers of timezones" instead of "Names of timezones".
We can emphasize the "identifier" stuff a bit more, as in the attached proposed patch. I'm leery of globally replacing "name" with "identifier" though, as "name" is shorter and makes the text easier to follow.
A second suggestion would be a short note that it is these identifiers which would be typically stored in database / system configuration / appointment in order to denote the time zone of a "thing" and that software will typically pick up the additional rule data in tzdb in order to compute meaningful things based on these identifiers. This is sort of implicit to the given text, but might be pointed out more explicitly.
While this may be common practice, I'm not sure we should recommend it as it's fragile in the presence of timezone splits. The proposed patch attempts to add a warning along these lines.
Thanks, both changes look good to me. Minor note: one might also want to align the URL label in the first bullet of https://data.iana.org/time-zones/theory.html#stability Best, Hans-Joerg -- audriga GmbH Durlacher Allee 47 76131 Karlsruhe, Germany Tel: +49 (0) 721 17029 316 Fax: +49 (0) 721 17029 3179 www.twitter.com/audriga <http://www.twitter.com/audriga> www.audriga.com <http://www.audriga.com/> Handelsregister: Amtsgericht Mannheim - HRB 713034 Sitz der Gesellschaft: Karlsruhe Geschäftsführer: Dr. Frank Dengler, Dr. Hans-Jörg Happel USt-ID: DE 279724142
On 2/20/19 8:37 AM, Hans-Joerg Happel wrote:
Minor note: one might also want to align the URL label in the first bullet of https://data.iana.org/time-zones/theory.html#stability
Thanks for catching that; I installed the attached.
On Feb 19, 2019, at 11:14 AM, Hans-Joerg Happel <happel@audriga.com> wrote:
Dear Paul,
thanks for the elaboration - further comments inline On 19.02.19 17:34, Paul Eggert wrote:
Hans-Joerg Happel wrote:
So any information on the rationale for the above-quoted rule is appreciated.
When I introduced locations as tzdb identifiers long ago, I naively put in one Zone or Link per country. Some users got accustomed to the idea that Zone and/or Link status was akin to political recognition of countries or their boundaries (is Kosovo a country? is Jerusalem part of Palestine? that sort of thing) and so I eventually realized my mistake: the identifiers are now supposed to be single locations, decoupled from countries or national regions.
At one point I attempted to simplify the database by coalescing regions that crossed country boundaries, since there's no longer any need to conflate the two. Unfortunately this flustered some users who thought this meant disrepect to particular countries (which was not the intent). After some back and forth we ended up with the current wording, which I'm not happy with, as the current rules are still too political and we still end up with "There should be an entry for Hanoi/Beijing/etc.!" discussions.
If this continues to be a sore spot, I'm inclined to adjust the rules so that there need not at least one Link or Zone per country. This should help simplify future maintenance if, say, the US splits into multiple countries (and stuff like that does happen). I'd see two different kinds of "maintenance" here:
* Maintenance of tzdb (which you are referring to) * Maintenance of systems/data by people using tzdb (directly or indirectly)
So in your example - if say, Washington (the federal state) would become a separate country, you argue to keep maintenance of tzdb low by sticking to "America/Los_Angeles", whereas one could argue for a link from "America/Seattle" (or the like) according to the current ISO 3166-1 rule in [1]. On the other hand, if Washington users could make use of such an "America/Seattle" alias, that could reduce maintenance effort in the event of of the new country of Washington deciding to deviate from "America/Los_Angeles" rules (which, as you say is stuff that will happen one or the other way).
Unfortunately, the tzdb maintainers *and* the tzdb users can't necessarily anticipate what additional zones might be created. America/Los_Angeles may, in the future, not be appropriate for Washington - or Oregon, even *without* the US dividing itself up: https://www.ballotpedia.org/California_Proposition_7,_Permanent_Daylight_Sav...) but you might not have to go back too far to find a time when few people would have predicted that. So I don't know how much prediction of future time changes we can do in order to decide what tzdb regions there should be.
My assumption (also in the US/Washington case above) is, that it is (in most cases) countries which do cast decisions about time zone rules.
It is, in most cases, governments that make those decisions; they may be national governments or regional governments within nations or a combination of the two.
Therefore, both Vietnam and Thailand seem to be free to change time zone rules at any time soon.
Yes (and to do so without much notice, as governments are sadly all too wont to do, provoking the usual scramble on the part of the tzdb maintainers and vendors shipping the tzdb).
Assuming two databases, one with "Vietnamese data" on an office server in Hanoi, one with "Thai data" on an office server in Bangkok, both databases would currently use "Asia/Bangkok" as an identifier.
So in case the Thai government decides to change time zone rules for Thailand (and Vietnam would not follow), if I am not wrong, this would most probably require tzdb to introduce an "Asia/Hanoi" identifier to accommodate for this new situation.
Yes.
However, people maintaining the server with "Vietnamese data" might then need to convert that data from using "Asia/Bangkok" to "Asia/Hanoi" (my example may sound a little simple or arbitrary, but I also want to understand if you share the idea that this may be a point).
Yes. Maybe this is *another* case where "some applications "misuse" tzdb identifiers" and where it might "be better to solve this on a more general level such as geo-location<=>timezone mappings", e.g. a meeting date shouldn't be tagged with {date/time, tzdb identifier} but with {date/time, geographic coordinates}. I'm not sure whether the geographic coordinates of the meeting location are more or less likely to change than the time zone rules of that location, but, with the geographic coordinates changing, that's probably a big enough change ("we've decided to move the meeting from Los Angeles, CA to Vancouver, BC") that the system can cope with it. It is, however, also a case where a "don't have tzdb regions that cover more than one country unless there's a good reason to believe that all countries within the region will coordinate their time zone offsets and summer time rules" rule might be a 90% solution.
Guy Harris said:
Maybe this is *another* case where "some applications "misuse" tzdb identifiers" and where it might "be better to solve this on a more general level such as geo-location<=>timezone mappings", e.g. a meeting date shouldn't be tagged with {date/time, tzdb identifier} but with {date/time, geographic coordinates}. I'm not sure whether the geographic coordinates of the meeting location are more or less likely to change than the time zone rules of that location,
That doesn't always solve the problem; it can make it worse. For example, I have a meeting which *I* take part in at my location, but is booked for 07:00 Seattle time, not 15:00 UK time. I don't want it tagged with my location. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646
On Feb 20, 2019, at 2:34 PM, Clive D.W. Feather <clive@davros.org> wrote:
Guy Harris said:
Maybe this is *another* case where "some applications "misuse" tzdb identifiers" and where it might "be better to solve this on a more general level such as geo-location<=>timezone mappings", e.g. a meeting date shouldn't be tagged with {date/time, tzdb identifier} but with {date/time, geographic coordinates}. I'm not sure whether the geographic coordinates of the meeting location are more or less likely to change than the time zone rules of that location,
That doesn't always solve the problem; it can make it worse.
For example, I have a meeting which *I* take part in at my location, but is booked for 07:00 Seattle time, not 15:00 UK time. I don't want it tagged with my location.
If that is a phone or online meeting, rather than an in-person meeting, it doesn't have *a single* location, right? At *most*, it has a "central" location, where the people coordinating the meeting reside, or something such as that, but that's not the location where the meeting is occurring. If the expectation is that the calendar software will automatically, through the Magic of the TZDB, show everybody the meeting time at their location, then it's going to have to keep track of the locations of all the participants, so it'll have to get tagged with the location of the (presumed) people in Seattle attending it, and the location of the people in the UK attending it, etc., so that the meeting might be tagged with the "central" location, *and* each participant would be tagged with their location at the time of the meeting.
On 2/20/19 17:50, Guy Harris wrote:
On Feb 20, 2019, at 2:34 PM, Clive D.W. Feather <clive@davros.org> wrote:
Guy Harris said:
Maybe this is *another* case where "some applications "misuse" tzdb identifiers" and where it might "be better to solve this on a more general level such as geo-location<=>timezone mappings", e.g. a meeting date shouldn't be tagged with {date/time, tzdb identifier} but with {date/time, geographic coordinates}. I'm not sure whether the geographic coordinates of the meeting location are more or less likely to change than the time zone rules of that location, That doesn't always solve the problem; it can make it worse.
For example, I have a meeting which *I* take part in at my location, but is booked for 07:00 Seattle time, not 15:00 UK time. I don't want it tagged with my location. If that is a phone or online meeting, rather than an in-person meeting, it doesn't have *a single* location, right? At *most*, it has a "central" location, where the people coordinating the meeting reside, or something such as that, but that's not the location where the meeting is occurring.
If the expectation is that the calendar software will automatically, through the Magic of the TZDB, show everybody the meeting time at their location, then it's going to have to keep track of the locations of all the participants, so it'll have to get tagged with the location of the (presumed) people in Seattle attending it, and the location of the people in the UK attending it, etc., so that the meeting might be tagged with the "central" location, *and* each participant would be tagged with their location at the time of the meeting.
Absolutely - one of the intentions of the extensions to the calendar specs. In this age of online meetings the attendees (intended) location - at the time of the meeting - becomes much more important. The location of the meeting itself then becomes a matter of what is most appropriate - perhaps the organizers location or a room if some people are local.
On 2019-02-20 16:13, Michael Douglass wrote:
On 2/20/19 17:50, Guy Harris wrote:
On Feb 20, 2019, at 2:34 PM, Clive D.W. Feather wrote:
Guy Harris said:
Maybe this is *another* case where "some applications "misuse" tzdb identifiers" and where it might "be better to solve this on a more general level such as geo-location<=>timezone mappings", e.g. a meeting date shouldn't be tagged with {date/time, tzdb identifier} but with {date/time, geographic coordinates}. I'm not sure whether the geographic coordinates of the meeting location are more or less likely to change than the time zone rules of that location, That doesn't always solve the problem; it can make it worse.
For example, I have a meeting which *I* take part in at my location, but is booked for 07:00 Seattle time, not 15:00 UK time. I don't want it tagged with my location. If that is a phone or online meeting, rather than an in-person meeting, it doesn't have *a single* location, right? At *most*, it has a "central" location, where the people coordinating the meeting reside, or something such as that, but that's not the location where the meeting is occurring.
If the expectation is that the calendar software will automatically, through the Magic of the TZDB, show everybody the meeting time at their location, then it's going to have to keep track of the locations of all the participants, so it'll have to get tagged with the location of the (presumed) people in Seattle attending it, and the location of the people in the UK attending it, etc., so that the meeting might be tagged with the "central" location, *and* each participant would be tagged with their location at the time of the meeting.
Absolutely - one of the intentions of the extensions to the calendar specs.
In this age of online meetings the attendees (intended) location - at the time of the meeting - becomes much more important.
The location of the meeting itself then becomes a matter of what is most appropriate - perhaps the organizers location or a room if some people are local.
My expectation is that the meeting organizer schedules an event at their reference location(s), in those locations' time zones, and attendees may display the event in the time zone for their default, current, or other location. When I say locations, that allows for an event being a flight or trip from one location to another in a different time zone. My expectation is that I can associate each location with a time zone for an extended period of time, and if the time zone in effect at that location changes, I can change that association, effectively providing my own gazetteer of time zones for locations of interest to me. Larger organizations may provide and update gazetteers with their systems so that I need not associate time zones with locations. Vendors and distros have the choice of competing by providing superior gazetteers at their own expense, or they could collaborate to provide superior gazetteers at reduced expense, and compete by providing superior interfaces and uses on their systems. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised.
On 2019-02-21 12:27:50 (+0900), Brian Inglis wrote:
On 2019-02-20 16:13, Michael Douglass wrote:
On 2/20/19 17:50, Guy Harris wrote:
On Feb 20, 2019, at 2:34 PM, Clive D.W. Feather wrote:
Guy Harris said:
Maybe this is *another* case where "some applications "misuse" tzdb identifiers" and where it might "be better to solve this on a more general level such as geo-location<=>timezone mappings", e.g. a meeting date shouldn't be tagged with {date/time, tzdb identifier} but with {date/time, geographic coordinates}. I'm not sure whether the geographic coordinates of the meeting location are more or less likely to change than the time zone rules of that location,
That doesn't always solve the problem; it can make it worse.
For example, I have a meeting which *I* take part in at my location, but is booked for 07:00 Seattle time, not 15:00 UK time. I don't want it tagged with my location.
If that is a phone or online meeting, rather than an in-person meeting, it doesn't have *a single* location, right? At *most*, it has a "central" location, where the people coordinating the meeting reside, or something such as that, but that's not the location where the meeting is occurring.
If the expectation is that the calendar software will automatically, through the Magic of the TZDB, show everybody the meeting time at their location, then it's going to have to keep track of the locations of all the participants, so it'll have to get tagged with the location of the (presumed) people in Seattle attending it, and the location of the people in the UK attending it, etc., so that the meeting might be tagged with the "central" location, *and* each participant would be tagged with their location at the time of the meeting.
Absolutely - one of the intentions of the extensions to the calendar specs.
In this age of online meetings the attendees (intended) location - at the time of the meeting - becomes much more important.
The location of the meeting itself then becomes a matter of what is most appropriate - perhaps the organizers location or a room if some people are local.
My expectation is that the meeting organizer schedules an event at their reference location(s), in those locations' time zones, and attendees may display the event in the time zone for their default, current, or other location.
That seems to be the way things work in my experience in the "real world". Organiser: "We are having a meeting next Tuesday at 18:00 New York time". Regardless of where everyone else in the world happens to be. I expect calendar software to make a note of the "New York time" and alert me around 17:30 New York time, even if I happen to be in Hong Kong at the time (and probably wishing to be asleep). And in the real world, that has to be robust in the face of daylight saving and other silliness. If New York decides to move to a different UTC offset the night before, but Hong Kong doesn't, I still want to be alerted at 17:30 New York time. Even if that's at a different offset than it was when the meeting was originally scheduled.
When I say locations, that allows for an event being a flight or trip from one location to another in a different time zone.
It also allows one to schedule an event in a third location. E.g. you schedule a meeting at 18:00 next Tuesday in New York while you are in Hong Kong knowing that you'll be in London the day of the meeting. Regardless of where you happen to be, you still want the alert when people in New York agree it's 17:30 on Tuesday.
My expectation is that I can associate each location with a time zone for an extended period of time, and if the time zone in effect at that location changes, I can change that association, effectively providing my own gazetteer of time zones for locations of interest to me.
Larger organizations may provide and update gazetteers with their systems so that I need not associate time zones with locations.
Precisely. Users don't want to care about that. Users also don't want to have to worry about the time differences changing for whatever reason -- whether daylight saving or political meddling. Users just want the alert half an hour before the meeting, whenever that happens to be. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
On Feb 20, 2019, at 7:27 PM, Brian Inglis <Brian.Inglis@SystematicSw.ab.ca> wrote:
My expectation is that the meeting organizer schedules an event at their reference location(s), in those locations' time zones, and attendees may display the event in the time zone for their default, current, or other location.
When I say locations, that allows for an event being a flight or trip from one location to another in a different time zone.
(I don't think of a flight as a meeting unless the meeting is being held on the aircraft, so presumably "meeting organizer schedules an event" should be "event organizer schedules an event", where "meeting organizers" is a subclass of "event organizers".) So, if the event is a flight, the event has a start time that's something such as "time to arrive at the airport from which the flight departs" or "time the flight takes off" and a duration or end time. In that case, if, for example, the flight organizer is in one location, and the flight is from another location and to another location, presumably the start and end times aren't scheduled in the flight organizer's location - is the beginning time scheduled in the departure airport's location and the end time scheduled in the arrival airport's location?
On 2019-02-20 21:51, Guy Harris wrote:
On Feb 20, 2019, at 7:27 PM, Brian Inglis wrote:
My expectation is that the meeting organizer schedules an event at their reference location(s), in those locations' time zones, and attendees may display the event in the time zone for their default, current, or other location. When I say locations, that allows for an event being a flight or trip from one location to another in a different time zone.
(I don't think of a flight as a meeting unless the meeting is being held on the aircraft, so presumably "meeting organizer schedules an event" should be "event organizer schedules an event", where "meeting organizers" is a subclass of "event organizers".)
There may be companion "attendees" on some business and often on personal trips.
So, if the event is a flight, the event has a start time that's something such as "time to arrive at the airport from which the flight departs" or "time the flight takes off" and a duration or end time.
I schedule events per the ticketed location(s) and times, with event alarms days or weeks before events, and reduce alarm lead times as events become imminent.
In that case, if, for example, the flight organizer is in one location, and the flight is from another location and to another location, presumably the start and end times aren't scheduled in the flight organizer's location - is the beginning time scheduled in the departure airport's location and the end time scheduled in the arrival airport's location?
That's why I said "at their reference location(s), in those locations' time zones" to allow a trip to be scheduled from NYC to LAX locations at each airport's local times as ticketed, regardless of the organizer's location. That could differ were we considering changing airline schedules for multiple aircraft based out of one base airport, and the base time zone for such schedules could be UTC regardless of location: a corollary of "Universal". -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised.
On 2019-02-20, at 20:27:50, Brian Inglis wrote:
My expectation is that the meeting organizer schedules an event at their reference location(s), in those locations' time zones, and attendees may display the event in the time zone for their default, current, or other location.
Does RFC 6047 help?: https://tools.ietf.org/html/rfc6047 I notice that a MacOS iCal event contains detailed timezone information not specified in RFC 6047 that would enable clients to implement Brian's wish. -- gil
On 2019-02-20 16:13, Michael Douglass wrote:
On 2/20/19 17:50, Guy Harris wrote:
On Feb 20, 2019, at 2:34 PM, Clive D.W. Feather wrote:
Guy Harris said:
Maybe this is *another* case where "some applications "misuse" tzdb identifiers" and where it might "be better to solve this on a more general level such as geo-location<=>timezone mappings", e.g. a meeting date shouldn't be tagged with {date/time, tzdb identifier} but with {date/time, geographic coordinates}. I'm not sure whether the geographic coordinates of the meeting location are more or less likely to change than the time zone rules of that location, That doesn't always solve the problem; it can make it worse.
For example, I have a meeting which *I* take part in at my location, but is booked for 07:00 Seattle time, not 15:00 UK time. I don't want it tagged with my location. If that is a phone or online meeting, rather than an in-person meeting, it doesn't have *a single* location, right? At *most*, it has a "central" location, where the people coordinating the meeting reside, or something such as that, but that's not the location where the meeting is occurring.
If the expectation is that the calendar software will automatically, through the Magic of the TZDB, show everybody the meeting time at their location, then it's going to have to keep track of the locations of all the participants, so it'll have to get tagged with the location of the (presumed) people in Seattle attending it, and the location of the people in the UK attending it, etc., so that the meeting might be tagged with the "central" location, *and* each participant would be tagged with their location at the time of the meeting.
Absolutely - one of the intentions of the extensions to the calendar specs.
In this age of online meetings the attendees (intended) location - at the time of the meeting - becomes much more important.
The location of the meeting itself then becomes a matter of what is most appropriate - perhaps the organizers location or a room if some people are local.
My expectation is that the meeting organizer schedules an event at their reference location(s), in those locations' time zones, and attendees may display the event in the time zone for their default or current location. When I say locations, that allows for an event being a flight or trip from one location to another in a different time zone. My expectation is that I can associate each location with a time zone for an extended period of time, and if the time zone in effect at that location changes, I can change that association. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised.
Sorry for jumping in so late. I've been on a short vacation with very limited internet access, and have just read the emails in this thread. If the current time zone names should indeed just be taken as IDs rather than real names then IMO it would be very helpful if there also was a list of mappings provided that links readable display names to TZDB ID names. Otherwise each project has to do this by itself, and the problem seems to be that some projects just use the ID names from TZDB while other projects do the mapping by themselves. If there was a mapping list included with TZDB then different projects could rely to them and use the same, consistent information and displaying. Anyway, there's still a different point. I'm assuming that English is the native language for most members of this list, but most applications taking care about time zones let users select them zone in their native language, so some internationalization would also be very helpful. For example, the zone "Europe/Macedonia" is displayed as "Europa/Makedonien" on my Linux/KDE system set to German language. As far as I can see each project that has to deal with this kind of things has to provide the translations by themselves. Since TZDB is maintained on github I'd expect there would be quite some folks that were happy to provide translations for zone names, eventually exported from their own, local projects. Once such a mapping list has been set up it should not be to hard to maintain it, and those who make changes to the DB itself know best which of the mapped links would be affected by a particular change. Another point that has recently been discussed is how an event time is affected if the time zone rules change after the point in time where the event is created for some local time, and before the time the event happens. I think we'd have too distinguish a little bit. If there is a virtual meeting scheduled in local time for 11:30 New York time, and the New York time zone changes by 1 hour then I'd expect that the event time will still be 11:30 local time, but the event time for my location in Central Europe will change by 1 hour. On the other hand, if I've booked a flight for 11:30 New York time and the New York time zone changes then eventually the departure time may also change by 1 hour to keep the flight consistent with connection flights in other time zones. So it depends on the application, but in any case it would be helpful if at least the time zone names on my PC, on my smartphone, etc. would be consistent. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy
Martin Burnicki <martin.burnicki@meinberg.de> wrote:
For example, the zone "Europe/Macedonia" is displayed as "Europa/Makedonien" on my Linux/KDE system set to German language. As far as I can see each project that has to deal with this kind of things has to provide the translations by themselves.
Since TZDB is maintained on github I'd expect there would be quite some folks that were happy to provide translations for zone names, eventually exported from their own, local projects.
I thought this kind of thing was done by the CLDR, though it seems to map from TZ names to translated exemplar cities, which is slightly different than a direct translation of the TZ name.
Another point that has recently been discussed is how an event time is affected if the time zone rules change after the point in time where the event is created for some local time, and before the time the event happens.
The way to deal with this is to assign the event a sensible primary location, and do the mapping from location -> tz lazily on demand. However the standard data model (iCalendar) doesn't allow this. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Trafalgar: Mainly southeasterly 4 or 5, but easterly 6 to gale 8 in far southeast. Rough or very rough. Fair. Good.
On 2019-02-25 05:37, Tony Finch wrote:
Martin Burnicki <martin.burnicki@meinberg.de> wrote:
For example, the zone "Europe/Macedonia" is displayed as "Europa/Makedonien" on my Linux/KDE system set to German language. As far as I can see each project that has to deal with this kind of things has to provide the translations by themselves.
Since TZDB is maintained on github I'd expect there would be quite some folks that were happy to provide translations for zone names, eventually exported from their own, local projects.
I thought this kind of thing was done by the CLDR, though it seems to map from TZ names to translated exemplar cities, which is slightly different than a direct translation of the TZ name.
Another point that has recently been discussed is how an event time is affected if the time zone rules change after the point in time where the event is created for some local time, and before the time the event happens.
The way to deal with this is to assign the event a sensible primary location, and do the mapping from location -> tz lazily on demand. However the standard data model (iCalendar) doesn't allow this.
The sensible locations would be major cities and towns in each country's time zones. To support this apps need a common gazetteer to map from major cities and towns to tzids. GeoNames.org data provides timezones for many locations, is used by many orgs, and is a good base if the CC BY 4 licence conditions are acceptable https://creativecommons.org/licenses/by/4.0/ Creative Commons Attribution 4.0 License. Forums and mailing lists are hosted on Google groups. Pareto principle applies here, as most people in most countries currently use a single time zone, so a location mapping to a country defines their observed time zone; minorities observe different time zones for business, colonial, cultural, economic, geographic, historical, or social reasons; some countries, mainly in the Americas, require more than a single time zone because they spread widely across longitudes, with additional time zone variations because of the above differences; these countries and minorities need better mappings. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised.
Brian Inglis wrote:
On 2019-02-25 05:37, Tony Finch wrote:
Martin Burnicki <martin.burnicki@meinberg.de> wrote:
For example, the zone "Europe/Macedonia" is displayed as "Europa/Makedonien" on my Linux/KDE system set to German language. As far as I can see each project that has to deal with this kind of things has to provide the translations by themselves.
Since TZDB is maintained on github I'd expect there would be quite some folks that were happy to provide translations for zone names, eventually exported from their own, local projects.
I thought this kind of thing was done by the CLDR, though it seems to map from TZ names to translated exemplar cities, which is slightly different than a direct translation of the TZ name.
Another point that has recently been discussed is how an event time is affected if the time zone rules change after the point in time where the event is created for some local time, and before the time the event happens.
The way to deal with this is to assign the event a sensible primary location, and do the mapping from location -> tz lazily on demand. However the standard data model (iCalendar) doesn't allow this.
Yes, but as far as I have seen calendar apps often try to do the conversion, more or less successfully. For example, if I add a calendar event (e.g. using Thunderbird with Lightning addon) for a time in a different time zone and synchronize my phone via a caldav server then the displayed event time changes depending on the zone I'm currently in, or I've currently configured. This is expected, but if I edit the event then my phone may display a different zone name for the start/end times than Thunderbird's lightning, so a pure user may see that the current UTC offset is as expected, but he doesn't even know if the DST rules are the same for both displayed settings, or if they refer to different zones which accidentally have the same current UTC offset.
The sensible locations would be major cities and towns in each country's time zones. To support this apps need a common gazetteer to map from major cities and towns to tzids.
Yes, that's exactly what I meant.
GeoNames.org data provides timezones for many locations, is used by many orgs, and is a good base if the CC BY 4 licence conditions are acceptable https://creativecommons.org/licenses/by/4.0/ Creative Commons Attribution 4.0 License. Forums and mailing lists are hosted on Google groups.
Thanks for the pointer.
Pareto principle applies here, as most people in most countries currently use a single time zone, so a location mapping to a country defines their observed time zone; minorities observe different time zones for business, colonial, cultural, economic, geographic, historical, or social reasons; some countries, mainly in the Americas, require more than a single time zone because they spread widely across longitudes, with additional time zone variations because of the above differences; these countries and minorities need better mappings.
Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy
Tony Finch wrote:
Martin Burnicki <martin.burnicki@meinberg.de> wrote:
For example, the zone "Europe/Macedonia" is displayed as "Europa/Makedonien" on my Linux/KDE system set to German language. As far as I can see each project that has to deal with this kind of things has to provide the translations by themselves.
Since TZDB is maintained on github I'd expect there would be quite some folks that were happy to provide translations for zone names, eventually exported from their own, local projects.
I thought this kind of thing was done by the CLDR, ...
Oops, thanks, I didn't know CLDR before.
... though it seems to map from TZ names to translated exemplar cities, which is slightly different than a direct translation of the TZ name.
In my original email I tried to distinguish between the TZDB ID name (which of course doesn't have to be translated), and the names that are actually presented to the user when they select a time zone for their system, or add a calendar event with a time for a specific zone. The latter should be localized, IMO.
Another point that has recently been discussed is how an event time is affected if the time zone rules change after the point in time where the event is created for some local time, and before the time the event happens.
The way to deal with this is to assign the event a sensible primary location, and do the mapping from location -> tz lazily on demand. However the standard data model (iCalendar) doesn't allow this.
Agreed. I wanted to point out that either the "primary" local time may be kept unchanged if the rules for that zone change in the mean time, and the derived times for participant will change, or vice versa. This depends on the kind of event, and many people I know are not aware of this difference. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy
On Feb 26, 2019, at 12:32 AM, Martin Burnicki <martin.burnicki@meinberg.de> wrote:
Tony Finch wrote:
Martin Burnicki <martin.burnicki@meinberg.de> wrote: ... though it seems to map from TZ names to translated exemplar cities, which is slightly different than a direct translation of the TZ name.
In my original email I tried to distinguish between the TZDB ID name (which of course doesn't have to be translated), and the names that are actually presented to the user when they select a time zone for their system, or add a calendar event with a time for a specific zone. The latter should be localized, IMO.
The latter are not supplied by the tzdb, so they can't be localized by the tzdb developers. For example. there *is* no tzdb ID Europe/Macedonia. *That* was cooked up by somebody involved in the development of your Linux distribution or somebody, *other* than the tzdb developers, upstream of them. *They're* the ones who would need to localize the name. And what they really should be doing is: 1) ideally, trying to find out where your machine is, and picking the appropriate tzdb ID based on that (as my iPhone and Mac both do, by default - and, yes, they update the tzdb region when you move across zone boundaries, even updating the current tzdb regions for dumb UN*X programs that don't know that the region *can* change out from under them); 2) if they have no mechanism to find the machine's current coordinates (GPS, geolocation by looking at what known wireless networks are nearby, geolocation by finding the location of the nearest cell tower, etc.), either providing a map where the user can select a location, or by providing the name of the city or other locale they're in (as both the macOS tzdb region selector and the Ubuntu 18.04 tzdb region selector do); rather than just throwing an arbitrary list of *some* location names at the user.
On 26/02/2019 08:41, Guy Harris wrote:
rather than just throwing an arbitrary list of*some* location names at the user.
More likely to get the WHOLE tz list without even an option to select which continent! -- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
On Feb 26, 2019, at 12:57 AM, Lester Caine <lester@lsces.co.uk> wrote:
On 26/02/2019 08:41, Guy Harris wrote:
rather than just throwing an arbitrary list of*some* location names at the user.
More likely to get the WHOLE tz list without even an option to select which continent!
Any UI developer who chooses to do that should be banned from doing any UI development without adult supervision. Or, at least, banned from doing any tzdb region selection UI code before seeing both macOS's tzdb region selector and Ubuntu 18.04's tzdb region selector (Ubuntu, not Kubuntu) to see what *can* and *should* be done.
On Tue, 2019-02-26 at 01:05 -0800, Guy Harris wrote:
Any UI developer who chooses to do that should be banned from doing any UI development without adult supervision.
Or, at least, banned from doing any tzdb region selection UI code before seeing both macOS's tzdb region selector and Ubuntu 18.04's tzdb region selector (Ubuntu, not Kubuntu) to see what *can* and *should* be done.
Yes, they are very nice and a worthy model to follow. However, in the IoT world one often lacks the resources on the target platform for including such things. Another of the reasons one sees the tzdb identifiers show up in UIs with the frequency that they do (aside from programmer laziness) is that they are actually quite intuitive. I've yet to have a user need to ask me about how to set a timezone; once they see the dropdown, it's obvious how it works in 99.5% of use cases. While this can and does get nationalists of various stripes worked up on occasion (as evidenced here on a regular basis), it's still a perfectly viable tradeoff that can work very well indeed in resource-poor environments. Cheers! |---------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |---------------------------------------------------------------------| | When in doubt, use brute force. | | | | -- Ken Thompson | |---------------------------------------------------------------------|
On Feb 26, 2019, at 9:43 AM, Fred Gleason <fredg@paravelsystems.com> wrote:
Yes, they are very nice and a worthy model to follow. However, in the IoT world one often lacks the resources on the target platform for including such things.
Another of the reasons one sees the tzdb identifiers show up in UIs with the frequency that they do (aside from programmer laziness) is that they are actually quite intuitive. I've yet to have a user need to ask me about how to set a timezone;
Have you ever had one of them say "I'm in Beijing, but you're only offering me Shanghai"? Nothing obliges you to use the tzdb identifiers rather than, say, names that might not require knowing how tzdb region IDs are chosen, e.g. "China" as the name for Asia/Shanghai (and something else, such as Xinjiang or Urumqi, for Xinjiang time), other than your platform being *so* small that even a mapping from "names we offer to the user" to "tzdb region IDs" won't fit.
On Tue, 2019-02-26 at 11:06 -0800, Guy Harris wrote:
Have you ever had one of them say "I'm in Beijing, but you're only offering me Shanghai"?
Not yet, though I imagine it's just a matter of time. :)
Nothing obliges you to use the tzdb identifiers rather than, say, names that might not require knowing how tzdb region IDs are chosen, e.g. "China" as the name for Asia/Shanghai (and something else, such as Xinjiang or Urumqi, for Xinjiang time),
That is, unless you are an ethnic Han living in the Western Regions, in which case you probably want Asia/Shanghai after all. 'Automatic location detection' does not address that case well either. My basic take is this: civil timekeeping is quite complex enough as it is, without the arbitrary interposition of yet more layers of indirection in the zone indexing. In many (perhaps most?) applications, such indirection may be a necessary evil. However, anything that increases the overall global complexity of a system imposes a 'tax' of its own (both in system resources and in the ease with which the system can be modeled and understood in a programmers head). It's well to consider this cost in the overall context of the intended use case, platform capabilities and intended user audience. To issue a categorical imperative like 'tzdb identifiers should *never* be shown to users' is to short-circuit this entire delicate design process of weighing tradeoffs. Cheers! |---------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |---------------------------------------------------------------------| | But in our enthusiasm, we could not resist a radical overhaul of | | the system, in which all of its major weaknesses have been exposed, | | analyzed, and replaced with new weaknesses. | | | | -- Bruce Leverett | | "Register Allocation in Optimizing Compilers" | |---------------------------------------------------------------------|
On Feb 26, 2019, at 2:49 PM, Fred Gleason <fredg@paravelsystems.com> wrote:
... My basic take is this: civil timekeeping is quite complex enough as it is, without the arbitrary interposition of yet more layers of indirection in the zone indexing. In many (perhaps most?) applications, such indirection may be a necessary evil. However, anything that increases the overall global complexity of a system imposes a 'tax' of its own (both in system resources and in the ease with which the system can be modeled and understood in a programmers head). It's well to consider this cost in the overall context of the intended use case, platform capabilities and intended user audience. To issue a categorical imperative like 'tzdb identifiers should *never* be shown to users' is to short-circuit this entire delicate design process of weighing tradeoffs.
I see it the opposite way. Layered architectures exist everywhere, and for very good reasons. In the case of tzdb, the usual computer science arguments apply. In addition, political considerations are an additional reason for layering. We already have plenty of discussion relating to what countries are, where boundaries are, whether a particular spot on the map is illegally occupied and by whom, and so forth. Those can be dismissed as "out of scope" because tzdb only concerns itself with abstractions: subsets of the world that share a set of time offset rules starting from 1970. What relationship those abstractions have with countries, provinces, occupied territories, or whatnot, isn't our concern. A key consequence is that the identifiers are not, weren't intended to be, and must not be used as, human UI identifiers. That IS a categorical rule. It is ignored by a number of software products, but that would be their bug, not ours. We really do not want to add to our scope extraneous and contentious issues like "what is a country", "which country does town xyz belong to", "is region foo illegally occupied by armed forces from country bar" and so forth, all of which would become questions to be answered if we were to attempt to define user-meaningful identifiers. Once in a while it is suggested that all tzdb zones should be identified by random unique integers, or something like that. I'm more and more inclined to think that's a good idea, because it would once and for all shut down this confusion. paul
On 2/26/19 15:00, Paul.Koning@dell.com wrote:
Once in a while it is suggested that all tzdb zones should be identified by random unique integers, or something like that. I'm more and more inclined to think that's a good idea, because it would once and for all shut down this confusion.
Thank you
paul
On 2/26/19 15:00, Paul.Koning@dell.com wrote:
Once in a while it is suggested that all tzdb zones should be identified by random unique integers, or something like that. I'm more and more inclined to think that's a good idea, because it would once and for all shut down this confusion.
And there are now 70 messages on this thread - itself derived from a thread with 56 messages
paul
On Tue 2019-02-26T20:00:54+0000 Paul.Koning@dell.com hath writ:
Once in a while it is suggested that all tzdb zones should be identified by random unique integers, or something like that. I'm more and more inclined to think that's a good idea, because it would once and for all shut down this confusion.
This seems to be a proposal to 1) Move the arguments to be Somebody Else's Problem, somewhere else. 2) Break a lot of existing interfaces to achieve that goal. I cannot begin to calculate the cost of 2) but given the number of downstream interfaces which use tzdb it seems likely larger than the cost of tolerating the discussions on this list. -- 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
Steve Allen wrote in <20190226221745.GA19009@ucolick.org>: |On Tue 2019-02-26T20:00:54+0000 Paul.Koning@dell.com hath writ: |> Once in a while it is suggested that all tzdb zones should be |> identified by random unique integers, or something like that. I'm |> more and more inclined to think that's a good idea, because it would |> once and for all shut down this confusion. | |This seems to be a proposal to |1) Move the arguments to be Somebody Else's Problem, somewhere else. I had a message with almost the same content as what papa Koning said, but did not send it, last Saturday i think it was. Paul Eggert gave a really explosive example, and many others possibly exist (you will always find someone who is pissed by something, but this is .. land). I did not send it because i could not imagine something better. I think Paul Eggert himself imagined numeric identifiers. Then tzselect would say "zone 000105 has been chosen for you". Well. It is also harder for the maintainer i guess. Europe/00105 maybe. Maybe tzselect could simply dump the last five rules for the chosen one, instead of saying something else. |2) Break a lot of existing interfaces to achieve that goal. | |I cannot begin to calculate the cost of 2) but given the number of |downstream interfaces which use tzdb it seems likely larger than the |cost of tolerating the discussions on this list. Then again from America noises spread the world which made me frightened when thinking where my hands have been when i was a teenager! (Not to talk about my more adult hands.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
On 2/26/19 17:17, Steve Allen wrote: > On Tue 2019-02-26T20:00:54+0000 Paul.Koning@dell.com hath writ: >> Once in a while it is suggested that all tzdb zones should be >> identified by random unique integers, or something like that. I'm >> more and more inclined to think that's a good idea, because it would >> once and for all shut down this confusion. > This seems to be a proposal to > 1) Move the arguments to be Somebody Else's Problem, somewhere else. Yes - but also to provide a mechanism that makes it less of a problem > 2) Break a lot of existing interfaces to achieve that goal. > > I cannot begin to calculate the cost of 2) but given the number of > downstream interfaces which use tzdb it seems likely larger than the > cost of tolerating the discussions on this list. There's an easy backwards compatibility mode: 1. have a uid for every zone 2. Create a set of data mapping that uid on to names that look like the current names 3. Provide a backwards compatability mode to take that file (or another named file) and put the names back For unchanged downstream software it looks exactly the same. However now we have disassociated the zones from the name. Downstream users are free to create their own files if they wish and we can also set about finding a owner for that name file (cldr perhaps?) > > -- > 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
On 2019-02-27 12:29, Michael Douglass wrote: > On 2/26/19 17:17, Steve Allen wrote: >> On Tue 2019-02-26T20:00:54+0000 Paul. oning hath writ: >>> Once in a while it is suggested that all tzdb zones should be >>> identified by random unique integers, or something like that. I'm >>> more and more inclined to think that's a good idea, because it would >>> once and for all shut down this confusion. >> This seems to be a proposal to >> 1) Move the arguments to be Somebody Else's Problem, somewhere else. > Yes - but also to provide a mechanism that makes it less of a problem >> 2) Break a lot of existing interfaces to achieve that goal. >> I cannot begin to calculate the cost of 2) but given the number of >> downstream interfaces which use tzdb it seems likely larger than the >> cost of tolerating the discussions on this list. > There's an easy backwards compatibility mode: > 1. have a uid for every zone > 2. Create a set of data mapping that uid on to names that look like the current > names > 3. Provide a backwards compatability mode to take that file (or another named > file) and put the names back > For unchanged downstream software it looks exactly the same. However now we have > disassociated the zones from the name. Downstream users are free to create their > own files if they wish and we can also set about finding a owner for that name > file (cldr perhaps?) Changing tz ids from location names to numbers just means you need comments describing the locations in the time zone to which it applies, and the arguments become about the commentary instead of the ids, so you can never totally avoid the issues. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised.
On 2019-02-28 14:45:42 (+0900), Brian Inglis wrote:
Changing tz ids from location names to numbers just means you need comments describing the locations in the time zone to which it applies, and the arguments become about the commentary instead of the ids, so you can never totally avoid the issues.
I think I prefer the discussions on this mailing list to the pain of having to deal with numeric identifiers. The discussions, while tedious and repetitive, are invariably mostly civil and short-lived. Opaque identifiers would be a pain forever. Philip -- Philip Paeps Senior Reality Engineer Ministry of Information
On 2/28/19 00:45, Brian Inglis wrote: > On 2019-02-27 12:29, Michael Douglass wrote: >> On 2/26/19 17:17, Steve Allen wrote: >>> On Tue 2019-02-26T20:00:54+0000 Paul. oning hath writ: >>>> Once in a while it is suggested that all tzdb zones should be >>>> identified by random unique integers, or something like that. I'm >>>> more and more inclined to think that's a good idea, because it would >>>> once and for all shut down this confusion. >>> This seems to be a proposal to >>> 1) Move the arguments to be Somebody Else's Problem, somewhere else. >> Yes - but also to provide a mechanism that makes it less of a problem >>> 2) Break a lot of existing interfaces to achieve that goal. >>> I cannot begin to calculate the cost of 2) but given the number of >>> downstream interfaces which use tzdb it seems likely larger than the >>> cost of tolerating the discussions on this list. >> There's an easy backwards compatibility mode: >> 1. have a uid for every zone >> 2. Create a set of data mapping that uid on to names that look like the current >> names >> 3. Provide a backwards compatability mode to take that file (or another named >> file) and put the names back >> For unchanged downstream software it looks exactly the same. However now we have >> disassociated the zones from the name. Downstream users are free to create their >> own files if they wish and we can also set about finding a owner for that name >> file (cldr perhaps?) > Changing tz ids from location names to numbers just means you need comments > describing the locations in the time zone to which it applies, and the arguments > become about the commentary instead of the ids, so you can never totally avoid > the issues. That's possibly an issue but it's not a problem for this group. The arguments are focused on the maintainers of that set of names. This group has made themselves the maintainers of a set of politically sensitive names and they are going to have to deal with these requests/demands/pleas until something is done to disassociate themselves from the names. Yes - there are problems to be solved but if we don't make a start on what is technically a very simple problem we'll not get anywhere. We've made some pretty significant changes in calendaring over the last few years without the world coming to an end. The first step is to disentangle the apolitical data from the names - at source. Downstream from that we have to figure out how to avoid significant upheaval and don't think that's a major problem. Beyond the nuisance aspect of all this the use of such names is a bar to using this information in a number of systems. It may not be the only issue but it is one we can deal with. >
On 28/02/2019 06:03, Michael Douglass wrote:
Beyond the nuisance aspect of all this the use of such names is a bar to using this information in a number of systems. It may not be the only issue but it is one we can deal with.
And kick the problems of actually providing useful data to ALL systems further into the long grass? Many systems simply can't use the TZ data currently because there is no way of knowing just what version of data is provided with the CURRENT name. Hiding the data even further under even more isolated identifiers helps no-one. At the end of the day there has to be a system that when feed with a location can provide a reliable LIST of rules even if those rules include 'don't know' for times pre-1970. Pretending the likes of the time changes during the second world war never happened is just as political a decision as returning the wrong data for EXISTING rule sets currently! Any system using TZ currently should NOT return offsets for dates prior to 1970 ... That TZ IS currently only going to produce a subset of the rules and not even flag when those rules change seems to be a fact of life, so what IS needed now is to get tzdist running properly and for 'interested parties' to provide their own providers with their own set of names. The current set of rule names can then STILL be managed and provide a backward compatible source for current normalised data and more importantly flag where a timestamp IS outside of the scope of the data set! But there seems to be no interest in anybody providing such a service? -- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
On 2019-02-27 23:03, Michael Douglass wrote: > > On 2/28/19 00:45, Brian Inglis wrote: >> On 2019-02-27 12:29, Michael Douglass wrote: >>> On 2/26/19 17:17, Steve Allen wrote: >>>> On Tue 2019-02-26T20:00:54+0000 Paul. oning hath writ: >>>>> Once in a while it is suggested that all tzdb zones should be >>>>> identified by random unique integers, or something like that. I'm >>>>> more and more inclined to think that's a good idea, because it would >>>>> once and for all shut down this confusion. >>>> This seems to be a proposal to >>>> 1) Move the arguments to be Somebody Else's Problem, somewhere else. >>> Yes - but also to provide a mechanism that makes it less of a problem >>>> 2) Break a lot of existing interfaces to achieve that goal. >>>> I cannot begin to calculate the cost of 2) but given the number of >>>> downstream interfaces which use tzdb it seems likely larger than the >>>> cost of tolerating the discussions on this list. >>> There's an easy backwards compatibility mode: >>> 1. have a uid for every zone >>> 2. Create a set of data mapping that uid on to names that look like the current >>> names >>> 3. Provide a backwards compatability mode to take that file (or another named >>> file) and put the names back >>> For unchanged downstream software it looks exactly the same. However now we have >>> disassociated the zones from the name. Downstream users are free to create their >>> own files if they wish and we can also set about finding a owner for that name >>> file (cldr perhaps?) >> Changing tz ids from location names to numbers just means you need comments >> describing the locations in the time zone to which it applies, and the arguments >> become about the commentary instead of the ids, so you can never totally avoid >> the issues. > > That's possibly an issue but it's not a problem for this group. > > The arguments are focused on the maintainers of that set of names. This group > has made themselves the maintainers of a set of politically sensitive names and > they are going to have to deal with these requests/demands/pleas until something > is done to disassociate themselves from the names. > > Yes - there are problems to be solved but if we don't make a start on what is > technically a very simple problem we'll not get anywhere. We've made some pretty > significant changes in calendaring over the last few years without the world > coming to an end. > > The first step is to disentangle the apolitical data from the names - at source. > Downstream from that we have to figure out how to avoid significant upheaval > and don't think that's a major problem. > > Beyond the nuisance aspect of all this the use of such names is a bar to using > this information in a number of systems. It may not be the only issue but it is > one we can deal with. If we disassociate the ids from locations how does anyone make any sense or use of the data? You are pushing the problem down one level of indirection and dissociating meaning from content. The project has lasted and succeeded so long because it keeps to a few rules and tries not to needlessly perturb the base data. Feel free to fork the github experimental project data, try your ideas out, and let us know how the uptake goes? [Meaningful names help people comprehend - arbitrary identifiers are fine as long as they are hidden for use purely internally by systems as long as people never have to see or deal with them. When people quote me numeric codes or ids for anything, I always tell them that is meaningless to me, and ask them to explain in words. Some years ago there were methodologies promoted to use only numeric ids for all software components and variable names, and these were used in commercial systems. Unfortunately as the commentary and documentation were as good quality and well maintained as usual with commercial systems under time pressures, systems might as well have been written in binary as far as comprehension and maintenance went.] -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised.
On Feb 28, 2019, at 8:33 AM, Brian Inglis <Brian.Inglis@SystematicSw.ab.ca> wrote:
If we disassociate the ids from locations how does anyone make any sense or use of the data?
The ID for my location refers to a city about 500 km from my location. How does anyone make sense of that? Fortunately the OS on my laptop doesn't require me to say "America/Los_Angeles" to it; it's happy to let me specify the city I'm in, if I don't just let it select the tzdb region based on where it thinks I am right now. The same applies to the OS on my smartphone. And the OS on at least one of the virtual machines I have also lets me specify a nearby city, although not the city I'm in - maybe they didn't pick the biggest city database from GeoNames, so that the nearby city is in the database but the city I'm in isn't. (The OS's name is "Ubuntu" and its version number is 18.04.) IDs are associated with *a* location, but not necessarily with the location you're at, or even a location near where you're at, and not necessarily with a location in your country.
Brian Inglis wrote: > On 2019-02-27 23:03, Michael Douglass wrote: >> >> On 2/28/19 00:45, Brian Inglis wrote: >>> On 2019-02-27 12:29, Michael Douglass wrote: >>>> On 2/26/19 17:17, Steve Allen wrote: >>>>> On Tue 2019-02-26T20:00:54+0000 Paul. oning hath writ: >>>>>> Once in a while it is suggested that all tzdb zones should be >>>>>> identified by random unique integers, or something like that. I'm >>>>>> more and more inclined to think that's a good idea, because it would >>>>>> once and for all shut down this confusion. >>>>> This seems to be a proposal to >>>>> 1) Move the arguments to be Somebody Else's Problem, somewhere else. >>>> Yes - but also to provide a mechanism that makes it less of a problem >>>>> 2) Break a lot of existing interfaces to achieve that goal. >>>>> I cannot begin to calculate the cost of 2) but given the number of >>>>> downstream interfaces which use tzdb it seems likely larger than the >>>>> cost of tolerating the discussions on this list. >>>> There's an easy backwards compatibility mode: >>>> 1. have a uid for every zone >>>> 2. Create a set of data mapping that uid on to names that look like the current >>>> names >>>> 3. Provide a backwards compatability mode to take that file (or another named >>>> file) and put the names back >>>> For unchanged downstream software it looks exactly the same. However now we have >>>> disassociated the zones from the name. Downstream users are free to create their >>>> own files if they wish and we can also set about finding a owner for that name >>>> file (cldr perhaps?) >>> Changing tz ids from location names to numbers just means you need comments >>> describing the locations in the time zone to which it applies, and the arguments >>> become about the commentary instead of the ids, so you can never totally avoid >>> the issues. >> >> That's possibly an issue but it's not a problem for this group. >> >> The arguments are focused on the maintainers of that set of names. This group >> has made themselves the maintainers of a set of politically sensitive names and >> they are going to have to deal with these requests/demands/pleas until something >> is done to disassociate themselves from the names. >> >> Yes - there are problems to be solved but if we don't make a start on what is >> technically a very simple problem we'll not get anywhere. We've made some pretty >> significant changes in calendaring over the last few years without the world >> coming to an end. >> >> The first step is to disentangle the apolitical data from the names - at source. >> Downstream from that we have to figure out how to avoid significant upheaval >> and don't think that's a major problem. >> >> Beyond the nuisance aspect of all this the use of such names is a bar to using >> this information in a number of systems. It may not be the only issue but it is >> one we can deal with. > > If we disassociate the ids from locations how does anyone make any sense or use > of the data? > You are pushing the problem down one level of indirection and dissociating > meaning from content. On the one hand I sometimes read on this ML that the basic names used for the zones should only be taken as IDs, and not be displayed directly. On the other hand a pure numeric ID is hard to handle even for developers, so what if we used a combination of numeric and readable string as ID? This would make it more obvious to "external" developers that the IDs are not meant to be directly displayed, and eventually that would let them have a look at the theory file. I bet that many developers who are not very familiar with this stuff don't do this because they *assume* that the ID strings can be used directly. > The project has lasted and succeeded so long because it keeps to a few rules and > tries not to needlessly perturb the base data. This doesn't necessarily mean that there is no room for improvement. If you have a look at the whole picture and not only at the pure database (which is undoubtedly very precious) then you see there is not only little confusion on how to use it properly. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy
Michael Douglass wrote: > On 2/26/19 17:17, Steve Allen wrote: >> On Tue 2019-02-26T20:00:54+0000 Paul.Koning@dell.com hath writ: >>> Once in a while it is suggested that all tzdb zones should be >>> identified by random unique integers, or something like that. I'm >>> more and more inclined to think that's a good idea, because it would >>> once and for all shut down this confusion. >> This seems to be a proposal to >> 1) Move the arguments to be Somebody Else's Problem, somewhere else. > Yes - but also to provide a mechanism that makes it less of a problem >> 2) Break a lot of existing interfaces to achieve that goal. >> >> I cannot begin to calculate the cost of 2) but given the number of >> downstream interfaces which use tzdb it seems likely larger than the >> cost of tolerating the discussions on this list. > > There's an easy backwards compatibility mode: > > 1. have a uid for every zone > > 2. Create a set of data mapping that uid on to names that look like the > current names > > 3. Provide a backwards compatability mode to take that file (or another > named file) and put the names back > > For unchanged downstream software it looks exactly the same. However now > we have disassociated the zones from the name. Downstream users are free > to create their own files if they wish and we can also set about finding > a owner for that name file (cldr perhaps?) Exactly. In the short term you have compatibility for existing applications, and in the long term you can reduce the confusion caused by names that are meant to be just identifiers, but not names to be displayed, from the names that really are to be displayed. I know the sentence above is confusing, but that exactly reflects the underlying problem. ;-) Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy
On Tue, Feb 26, 2019 at 12:01 PM <Paul.Koning@dell.com> wrote:
On Feb 26, 2019, at 2:49 PM, Fred Gleason <fredg@paravelsystems.com> wrote:
... My basic take is this: civil timekeeping is quite complex enough as it is, without the arbitrary interposition of yet more layers of indirection in the zone indexing. In many (perhaps most?) applications, such indirection may be a necessary evil. However, anything that increases the overall global complexity of a system imposes a 'tax' of its own (both in system resources and in the ease with which the system can be modeled and understood in a programmers head). It's well to consider this cost in the overall context of the intended use case, platform capabilities and intended user audience. To issue a categorical imperative like 'tzdb identifiers should *never* be shown to users' is to short-circuit this entire delicate design process of weighing tradeoffs.
I see it the opposite way. Layered architectures exist everywhere, and for very good reasons.
In the case of tzdb, the usual computer science arguments apply. In addition, political considerations are an additional reason for layering. We already have plenty of discussion relating to what countries are, where boundaries are, whether a particular spot on the map is illegally occupied and by whom, and so forth. Those can be dismissed as "out of scope" because tzdb only concerns itself with abstractions: subsets of the world that share a set of time offset rules starting from 1970. What relationship those abstractions have with countries, provinces, occupied territories, or whatnot, isn't our concern.
Adding political issues to taxdb's scope would necessarily result in segmenting the tzdb list/community anyway, simply out of volume-caused necessity if not just interest. Leave the political stuff to those more equipped to deal with it. (I'm admittedly biased toward the hierarchical as a data guy :) )
...
Once in a while it is suggested that all tzdb zones should be identified by random unique integers, or something like that. I'm more and more inclined to think that's a good idea, because it would once and for all shut down this confusion.
I wouldn't mind using a scheme similar to the often-used host-naming convention of using unrelated taxonomies (e.g., animals, gemstones, elements) as being easier to remember than random IDs like 0x7c5f or Windows locale IDs. I guess we might have arguments over primacy of names like "tiger" and "diamond" though. -- Alan Mintz <Alan.Mintz@gMail.com>
Paul.Koning@dell.com wrote:
On Feb 26, 2019, at 2:49 PM, Fred Gleason <fredg@paravelsystems.com> wrote:
... My basic take is this: civil timekeeping is quite complex enough as it is, without the arbitrary interposition of yet more layers of indirection in the zone indexing. In many (perhaps most?) applications, such indirection may be a necessary evil. However, anything that increases the overall global complexity of a system imposes a 'tax' of its own (both in system resources and in the ease with which the system can be modeled and understood in a programmers head). It's well to consider this cost in the overall context of the intended use case, platform capabilities and intended user audience. To issue a categorical imperative like 'tzdb identifiers should *never* be shown to users' is to short-circuit this entire delicate design process of weighing tradeoffs.
I see it the opposite way. Layered architectures exist everywhere, and for very good reasons.
In the case of tzdb, the usual computer science arguments apply. In addition, political considerations are an additional reason for layering. We already have plenty of discussion relating to what countries are, where boundaries are, whether a particular spot on the map is illegally occupied and by whom, and so forth. Those can be dismissed as "out of scope" because tzdb only concerns itself with abstractions: subsets of the world that share a set of time offset rules starting from 1970. What relationship those abstractions have with countries, provinces, occupied territories, or whatnot, isn't our concern.
A key consequence is that the identifiers are not, weren't intended to be, and must not be used as, human UI identifiers. That IS a categorical rule. It is ignored by a number of software products, but that would be their bug, not ours. We really do not want to add to our scope extraneous and contentious issues like "what is a country", "which country does town xyz belong to", "is region foo illegally occupied by armed forces from country bar" and so forth, all of which would become questions to be answered if we were to attempt to define user-meaningful identifiers.
Once in a while it is suggested that all tzdb zones should be identified by random unique integers, or something like that. I'm more and more inclined to think that's a good idea, because it would once and for all shut down this confusion.
I fully agree to the above. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy
On Feb 26, 2019, at 11:49 AM, Fred Gleason <fredg@paravelsystems.com> wrote:
On Tue, 2019-02-26 at 11:06 -0800, Guy Harris wrote:
Nothing obliges you to use the tzdb identifiers rather than, say, names that might not require knowing how tzdb region IDs are chosen, e.g. "China" as the name for Asia/Shanghai (and something else, such as Xinjiang or Urumqi, for Xinjiang time),
That is, unless you are an ethnic Han living in the Western Regions, in which case you probably want Asia/Shanghai after all.
Is an ethnic Han living there less likely to realize that "China" is more appropriate than "Xinjiang" or "Urumqi" for them than they are to realize that "Asia/Shanghai" is more appropriate than "Asia/Urumqi"? If so, why?
My basic take is this: civil timekeeping is quite complex enough as it is, without the arbitrary interposition of yet more layers of indirection in the zone indexing. In many (perhaps most?) applications, such indirection may be a necessary evil. However, anything that increases the overall global complexity of a system imposes a 'tax' of its own (both in system resources and in the ease with which the system can be modeled and understood in a programmers head). It's well to consider this cost in the overall context of the intended use case, platform capabilities and intended user audience. To issue a categorical imperative like 'tzdb identifiers should *never* be shown to users' is to short-circuit this entire delicate design process of weighing tradeoffs.
So presumably the tradeoff here is implementation complexity that the programmer's brain has to deal with vs. UI complexity that the end user's brain has to deal with, with the indirection taking away UI complexity for the end user (i.e., having to understand about the notion of tzdb regions and their IDs).
On Tue, 2019-02-26 at 12:14 -0800, Guy Harris wrote:
Is an ethnic Han living there less likely to realize that "China" is more appropriate than "Xinjiang" or "Urumqi" for them than they are to realize that "Asia/Shanghai" is more appropriate than "Asia/Urumqi"? If so, why?
I suspect that there would be a fair amount of experimentation in either case, until the user found the 'correct' setting --i.e. the one that made his clock match that of the people around him with which he interacts.
So presumably the tradeoff here is implementation complexity that the programmer's brain has to deal with vs. UI complexity that the end user's brain has to deal with, with the indirection taking away UI complexity for the end user (i.e., having to understand about the notion of tzdb regions and their IDs).
Exactly correct, which is why the intended audience must be taken into account when considering these tradeoffs. If that audience is "Aunt Millie on her cellphone", then I quite agree that presenting raw tzdb IDs is not the optimum UI choice. OTOH, if that audience consists of (say) professional engineers who deal with these sorts of issues routinely, then yes, they want the tzdb IDs, not some interpreted version of what I think they 'really' meant. Perhaps a real-life example would help. I used to do a fair amount of work with the Internet Domain Name System (DNS). That community has evolved a set of specific, very precise terms for describing various DNS attributes, such as 'host', 'zone', and 'record'. The problem domain is somewhat complex, and precision is important to understanding and communicating what it is that one is trying to accomplish. However, certain domain name registrars (names omitted here to protect the guilty) have seen fit to completely eschew the use of these terms in their management UIs (doubtless because they would be 'too intimidating' for Aunt Millie to deal with when setting up her web site for selling her home baked cupcakes). The result is to make them nearly incomprehensible to a person who *does* understand the problem domain. For example, what does changing 'the location to which the domain points' actually *mean*? A change to the 'A' record of the top level domain, or to the 'www' host? Or both? Or something else? How about if you have multiple hosts assigned to the domain, not just 'your web site'? And so on... I don't disagree with providing appropriate interfaces for non- technical users where that's necessary. I do however disagree with sweeping statements to the effect that such 'interpreted' views are the *only* acceptable forms in which tzdb data may be displayed. In particular, I disagree with certain proposals I've seen here, such as to replace the existing location identifiers with opaque alpha-numeric strings. That strikes me as adding pointless complexity, merely for the sake of forcing UI designers to add that extra layer of indirection through some other registry (which will, inevitably, then have to deal with all of the arguments about names/spelling/orthographies/etc that we see here on a regular basis). Civil time (like most things having to do with human culture) is inherently messy and idiocyncratic. Let's not make it even more complex than it needs to be. Cheers! |---------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |---------------------------------------------------------------------| | When you feel the urge to design a complex binary file format, | | it's generally wise to lie down until the feeling passes. | | | | -- Eric Raymond | | "The Art of UNIX Programming" | |---------------------------------------------------------------------|
On Feb 26, 2019, at 1:32 PM, Fred Gleason <fredg@paravelsystems.com> wrote:
On Tue, 2019-02-26 at 12:14 -0800, Guy Harris wrote:
Is an ethnic Han living there less likely to realize that "China" is more appropriate than "Xinjiang" or "Urumqi" for them than they are to realize that "Asia/Shanghai" is more appropriate than "Asia/Urumqi"? If so, why?
I suspect that there would be a fair amount of experimentation in either case, until the user found the 'correct' setting --i.e. the one that made his clock match that of the people around him with which he interacts.
Or you just put an explanation in the documentation for the western areas of China for their benefit.
So presumably the tradeoff here is implementation complexity that the programmer's brain has to deal with vs. UI complexity that the end user's brain has to deal with, with the indirection taking away UI complexity for the end user (i.e., having to understand about the notion of tzdb regions and their IDs).
Exactly correct, which is why the intended audience must be taken into account when considering these tradeoffs. If that audience is "Aunt Millie on her cellphone", then I quite agree that presenting raw tzdb IDs is not the optimum UI choice. OTOH, if that audience consists of (say) professional engineers who deal with these sorts of issues routinely, then yes, they want the tzdb IDs, not some interpreted version of what I think they 'really' meant.
Actually, that's not a question of "pushing complexity away from the programmers", it's a question of "users who don't need to know the details, and whose heads would probably explode if forced to deal with the details" vs. "users who need, for technical reasons, to deal with the details". People who deal with those issues and therefore have to know about tzdb regions should be clueful enough to know that the tzdb IDs are chosen not as user-friendly names and, therefore, that "but I'm in City X, not City Y!" is a complaint that should and will receive little sympathy here, as the Theory file states the rules we use to select the city, and "that's not how we pronounce the city's name" is a complaint to be addressed by getting the English-speaking community to change the name they use for the city (cf. Bombay -> Mumbai). So, for that subset of professional engineers who have to know about not just time zones and summer time in general, but about tzdb regions in particular, you can use tzdb IDs. If there are are engineers who have to know about tzdb regions, but aren't yet familiar with the tzdb, the documentation for whatever product is being discussed should explain it to them - including the rules from the Theory file, so they understand that the names don't necessarily correspond to, and aren't intended to correspond to, the layman's notion of the name for a "time zone", or "the most important city in z time zone, for some definition of "most important"", or anything such as that.
On Tue, 2019-02-26 at 14:03 -0800, Guy Harris wrote:
Actually, that's not a question of "pushing complexity away from the programmers", it's a question of "users who don't need to know the details, and whose heads would probably explode if forced to deal with the details" vs. "users who need, for technical reasons, to deal with the details".
Yes, that's a better way to put it.
People who deal with those issues and therefore have to know about tzdb regions should be clueful enough to know that the tzdb IDs are chosen not as user-friendly names and, therefore, that "but I'm in City X, not City Y!" is a complaint that should and will receive little sympathy here, as the Theory file states the rules we use to select the city, and "that's not how we pronounce the city's name" is a complaint to be addressed by getting the English-speaking community to change the name they use for the city (cf. Bombay -> Mumbai).
So, for that subset of professional engineers who have to know about not just time zones and summer time in general, but about tzdb regions in particular, you can use tzdb IDs.
Yup. It's a numerically small group I know, but is the one I primarily serve. Don't forget about us! :)
If there are are engineers who have to know about tzdb regions, but aren't yet familiar with the tzdb, the documentation for whatever product is being discussed should explain it to them - including the rules from the Theory file, so they understand that the names don't necessarily correspond to, and aren't intended to correspond to, the layman's notion of the name for a "time zone", or "the most important city in z time zone, for some definition of "most important"", or anything such as that.
Basically, just provide a link to the Theory file. Cheers! |---------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |---------------------------------------------------------------------| | There are two ways of constructing a software design. One is to | | make it so simple that there are obviously no deficiencies; the | | other is to make it so complicated that there are no obvious | | deficiencies. The first method is far more difficult. | | | | -- C.A.R Hoare | |---------------------------------------------------------------------|
On Feb 26, 2019, at 2:22 PM, Fred Gleason <fredg@paravelsystems.com> wrote:
Basically, just provide a link to the Theory file.
...and send patches to Paul for anything that it turns out the Theory file doesn't sufficiently explain (as in "one of our customers doesn't get why XXX").
On 26/02/2019 22:03, Guy Harris wrote:
If there are are engineers who have to know about tzdb regions, but aren't yet familiar with the tzdb, the documentation for whatever product is being discussed should explain it to them - including the rules from the Theory file, so they understand that the names don't necessarily correspond to, and aren't intended to correspond to, the layman's notion of the name for a "time zone", or "the most important city in z time zone, for some definition of "most important"", or anything such as that.
The other area here that gets totally ignored is historic changes to the rules. And while my own annoyance is the lack of pre-1970 clarity, it's CURRENT historic changes that are more important. If a OS simply updates from one version of TZ to the next there is no provision to flag that the meeting that was booked for 9AM UTC next month is now at a different local time as the rule HAS changed. This in my book is a lot more important to be flagged than any problem with the name of the rules being used? That a location may now be using a different rule set due to a boundary change is one aspect, but that the currently selected rule set has changed IS within the confines of TZ ... simply pretending that all that exists is the current version has always been wrong. Where the NAME of the rule set becomes more important is my other irritation ... the provision by the browser of JUST a current time offset. This hole in the system needs plugging so that the browser CAN identify the rule set being used so one knows if the client really has a fixed time offset, or next month that offset will be different ... -- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
Guy Harris wrote:
On Feb 26, 2019, at 12:32 AM, Martin Burnicki <martin.burnicki@meinberg.de> wrote:
Tony Finch wrote:
Martin Burnicki <martin.burnicki@meinberg.de> wrote: ... though it seems to map from TZ names to translated exemplar cities, which is slightly different than a direct translation of the TZ name.
In my original email I tried to distinguish between the TZDB ID name (which of course doesn't have to be translated), and the names that are actually presented to the user when they select a time zone for their system, or add a calendar event with a time for a specific zone. The latter should be localized, IMO.
The latter are not supplied by the tzdb, so they can't be localized by the tzdb developers.
OK, I've learned that this is handled by CLDR and similar projects, but anyway it would be good to have more consistent information.
For example. there *is* no tzdb ID Europe/Macedonia. *That* was cooked up by somebody involved in the development of your Linux distribution or somebody, *other* than the tzdb developers, upstream of them. *They're* the ones who would need to localize the name.
As shown in my reply to Paul this is listed by the tzselect utility which is part of the "timezone" package of my Linux system. I have to admit, though, that the package is somewhat older. Anyway, I just picked this up as an example.
And what they really should be doing is:
1) ideally, trying to find out where your machine is, and picking the appropriate tzdb ID based on that (as my iPhone and Mac both do, by default - and, yes, they update the tzdb region when you move across zone boundaries, even updating the current tzdb regions for dumb UN*X programs that don't know that the region *can* change out from under them);
2) if they have no mechanism to find the machine's current coordinates (GPS, geolocation by looking at what known wireless networks are nearby, geolocation by finding the location of the nearest cell tower, etc.), either providing a map where the user can select a location, or by providing the name of the city or other locale they're in (as both the macOS tzdb region selector and the Ubuntu 18.04 tzdb region selector do);
rather than just throwing an arbitrary list of *some* location names at the user.
Agreed, but in any case there needs to be some mapping so that a normal user can see that the correct timezone is proposed by default, or can be selected for the region where he's living. This can be hard for regions like Ukraine or Liberland, as I mentioned in one of my other emails. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy
On Feb 26, 2019, at 1:18 AM, Martin Burnicki <martin.burnicki@meinberg.de> wrote:
Agreed, but in any case there needs to be some mapping so that a normal user can see that the correct timezone is proposed by default, or can be selected for the region where he's living.
A normal user probably doesn't even want to know what the heck a tzdb region *is*. All they want is that the clock face on their smartwatch/clock on their smartphone/clock in the bar at the top or bottom of their screen display the correct current date and time, that their file manager report the correct creation/modification date and time for files, etc.. Thus, all that's needed is a way to determine where the machine is, either automatically (the best solution, if you have sufficient hardware and, for non-satnav receiver hardware, access to databases to map whatever "what radio station am I talking to" information it gets into an approximate location) or manually (by specifying, for example, the city/town/village you're in or near) and to map that to the appropriate tzdb region; there's nothing that the normal user *needs* to see.
This can be hard for regions like Ukraine or Liberland, as I mentioned in one of my other emails.
For Liberland: If you have the "automatically" solution, your coordinates get mapped to Europe/Belgrade. That mapping is nothing that the normal user needs to know, any more than they need to know the programming language in which the software running on their machine is written, or that selecting Switzerland under Europe as their location, and German as their preferred language, means they'll get a LANG environment variable containing "de_CH". If you have only the "manually" solution, the biggest problem is that Liberland: https://en.wikipedia.org/wiki/Liberland does not yet appear to have any cities, so the tzdb region selector would have to take the name of the country, in any of the languages in which it has a name, and map it to Europe/Belgrade. Again, that mapping is nothing that the normal user needs to know. For Ukraine: If you have the "automatically" solution, your coordinates get mapped to Europe/Kiev. That mapping is nothing that the normal user needs to know. If you have the "manually" solution, you'd enter the name of your city (or a nearby city) into the selector, in the appropriate language (which wouldn't mean "Kyiv", it'd mean something such as Київ if you're using Ukrainian), and it would get mapped to Europe/Kiev. That mapping is nothing that the normal user needs to know. If a normal user wants to see what tzdb region is being used, the UI should give, for example, the name of the city they selected (if they selected one), the name of the nearest city based on where the machine is, or the name of a "representative" city; it should *NOT* cough up some tzdb ID. If some nerd (i.e., *not* a normal user) wants to know the tzdb region, they can do "ls -l /etc/localtime" and see what it's symlinked to.
We have LLT/LiberLand time in production and some customers with liberland passports are using it. Easiest would just be if Belgrade could be copied into Europe/Liberland as a new entry to solve it :) On 2/26/19 11:48 AM, Guy Harris wrote:
On Feb 26, 2019, at 1:18 AM, Martin Burnicki <martin.burnicki@meinberg.de> wrote:
Agreed, but in any case there needs to be some mapping so that a normal user can see that the correct timezone is proposed by default, or can be selected for the region where he's living. A normal user probably doesn't even want to know what the heck a tzdb region *is*. All they want is that the clock face on their smartwatch/clock on their smartphone/clock in the bar at the top or bottom of their screen display the correct current date and time, that their file manager report the correct creation/modification date and time for files, etc..
Thus, all that's needed is a way to determine where the machine is, either automatically (the best solution, if you have sufficient hardware and, for non-satnav receiver hardware, access to databases to map whatever "what radio station am I talking to" information it gets into an approximate location) or manually (by specifying, for example, the city/town/village you're in or near) and to map that to the appropriate tzdb region; there's nothing that the normal user *needs* to see.
This can be hard for regions like Ukraine or Liberland, as I mentioned in one of my other emails. For Liberland:
If you have the "automatically" solution, your coordinates get mapped to Europe/Belgrade. That mapping is nothing that the normal user needs to know, any more than they need to know the programming language in which the software running on their machine is written, or that selecting Switzerland under Europe as their location, and German as their preferred language, means they'll get a LANG environment variable containing "de_CH".
If you have only the "manually" solution, the biggest problem is that Liberland:
https://en.wikipedia.org/wiki/Liberland
does not yet appear to have any cities, so the tzdb region selector would have to take the name of the country, in any of the languages in which it has a name, and map it to Europe/Belgrade. Again, that mapping is nothing that the normal user needs to know.
For Ukraine:
If you have the "automatically" solution, your coordinates get mapped to Europe/Kiev. That mapping is nothing that the normal user needs to know.
If you have the "manually" solution, you'd enter the name of your city (or a nearby city) into the selector, in the appropriate language (which wouldn't mean "Kyiv", it'd mean something such as Київ if you're using Ukrainian), and it would get mapped to Europe/Kiev. That mapping is nothing that the normal user needs to know.
If a normal user wants to see what tzdb region is being used, the UI should give, for example, the name of the city they selected (if they selected one), the name of the nearest city based on where the machine is, or the name of a "representative" city; it should *NOT* cough up some tzdb ID.
If some nerd (i.e., *not* a normal user) wants to know the tzdb region, they can do "ls -l /etc/localtime" and see what it's symlinked to.
On Feb 26, 2019, at 8:30 AM, filip <filip@firosolutions.com> wrote:
We have LLT/LiberLand time in production and some customers with liberland passports are using it.
Easiest would just be if Belgrade could be copied into Europe/Liberland as a new entry to solve it :)
Easiest would be for users not to have to care about tzdb IDs and just type "Liberland" into the time zone selector and get Europe/Belgrade or whatever is appropriate (if, for example, Liberland and its neighbors end up using different summer time rules). You may have to add an entry for Liberland to the GeoNames database: https://www.geonames.org/manual.html
On Tue, 2019-02-26 at 01:48 -0800, Guy Harris wrote:
All they want is that the clock face on their smartwatch/clock on their smartphone/clock in the bar at the top or bottom of their screen display the correct current date and time, that their file manager report the correct creation/modification date and time for files, etc..
Not always! For example, we make an embedded IoT product that allows up to six date/time displays to be shown simultaneously, each configurable to use a different time zone. In that particular use case, the 'determine my time zone automatically' method is not only irrelevant, but can be positively harmful. Cheers! |---------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |---------------------------------------------------------------------| | It's always good to take an orthogonal view of things. It develops | | ideas. | | | | -- Ken Thompson | |---------------------------------------------------------------------|
On Feb 26, 2019, at 9:54 AM, Fred Gleason <fredg@paravelsystems.com> wrote:
On Tue, 2019-02-26 at 01:48 -0800, Guy Harris wrote:
All they want is that the clock face on their smartwatch/clock on their smartphone/clock in the bar at the top or bottom of their screen display the correct current date and time, that their file manager report the correct creation/modification date and time for files, etc..
Not always!
For example, we make an embedded IoT product that allows up to six date/time displays to be shown simultaneously, each configurable to use a different time zone. In that particular use case, the 'determine my time zone automatically' method is not only irrelevant, but can be positively harmful.
There's a company that makes a handheld device that 1) uses the "determine my time zone automatically" method and 2) offers a display that shows multiple date/time displays, each one configurable to a location. That combination works Just Fine. I'm not sure whether that display can include a "where I am" entry; it's not even reporting my location correctly, it insists on calling it "Cupertino". (Yes, that's a spoiler; you can probably guess that the company in question is the same company whose time zone selector I've been giving as an example of the right way to do things. :-)) All the user who pops up World Clock on their iPhone wants is for those items to display the correct time and appropriate date indication ("Today", "Yesterday", or "Tomorrow", I suspect) - they really don't care that "Cupertino" means "America/Los_Angeles" (and probably don't want to get Theory.html cited at them to explain *why* "Cupertino" means "America/Los_Angeles") or.... The key here is "the user wants the times displayed right", not "the user wants to fiddle with tzdb IDs". Obviously, for clocks set to some time zone other than "local, whatever that might be", the user has to specify a location rather than have their location used automatically, but they care about *locations*, not about *tzdb regions* identified by tzdb IDs.
On 2019-02-26, at 12:18:15, Guy Harris wrote:
There's a company that makes a handheld device that 1) uses the "determine my time zone automatically" method and 2) offers a display that shows multiple date/time displays, each one configurable to a location. That combination works Just Fine.
In: https://aviation.stackexchange.com/questions/16818/why-does-aviation-use-zul... ... read the paragraph containing "Hopi". Ugh! If I set my device to "Airplane Mode" should it automatically switch to Zulu? -- gil
On Feb 26, 2019, at 11:56 AM, Paul Gilmartin via tz <tz@iana.org> wrote:
On 2019-02-26, at 12:18:15, Guy Harris wrote:
There's a company that makes a handheld device that 1) uses the "determine my time zone automatically" method and 2) offers a display that shows multiple date/time displays, each one configurable to a location. That combination works Just Fine.
In: https://aviation.stackexchange.com/questions/16818/why-does-aviation-use-zul...
... read the paragraph containing "Hopi".
Ugh!
Deborah, do the maps Apple has for tzdb regions (for location-to-region mapping) handle that case? (And does the software handle non-simply-connected regions?)
If I set my device to "Airplane Mode" should it automatically switch to Zulu?
Not if Core Location can and does use the accelerometer, in airplane mode, as an inertial guidance system - or if the GPS isn't turned off in airplane mode, which may, in fact, be the case. Otherwise, the question is whether the user's more likely to get confused by 1) switching to UTC or 2) remaining in the time zone you were in when you got the "handheld devices" message from the flight attendants.
Guy Harris wrote:
On Feb 26, 2019, at 9:54 AM, Fred Gleason <fredg@paravelsystems.com> wrote:
On Tue, 2019-02-26 at 01:48 -0800, Guy Harris wrote:
All they want is that the clock face on their smartwatch/clock on their smartphone/clock in the bar at the top or bottom of their screen display the correct current date and time, that their file manager report the correct creation/modification date and time for files, etc..
Not always!
For example, we make an embedded IoT product that allows up to six date/time displays to be shown simultaneously, each configurable to use a different time zone. In that particular use case, the 'determine my time zone automatically' method is not only irrelevant, but can be positively harmful.
There's a company that makes a handheld device that
1) uses the "determine my time zone automatically" method
It depends on what is used to determine the time zone automatically, a geolocation which can be ambiguous if you are close to some border, or e.g. the telecommunication network used by your handheld. Even the latter can be wrong. For example, I've visited the Canary Islands located in the Atlantic, in zone UTC+0, but these islands belong to Spain which is located in the zone UTC+1, so my handheld selected UTC+1 automatically, and I had to correct it manually to UTC+0 to have the real local time. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy
On Feb 28, 2019, at 2:29 AM, Martin Burnicki <martin.burnicki@meinberg.de> wrote:
It depends on what is used to determine the time zone automatically, a geolocation which can be ambiguous if you are close to some border, or e.g. the telecommunication network used by your handheld.
Even the latter can be wrong.
For example, I've visited the Canary Islands located in the Atlantic, in zone UTC+0, but these islands belong to Spain which is located in the zone UTC+1, so my handheld selected UTC+1 automatically, and I had to correct it manually to UTC+0 to have the real local time.
Deborah? Any idea what macOS/iOS/watchOS do in this case? (And does tvOS do geolocation, presumably via Wi-Fi and services such as Skyhook?)
On 2019-02-28, at 10:29:35, Martin Burnicki wrote:
For example, I've visited the Canary Islands located in the Atlantic, in zone UTC+0, but these islands belong to Spain which is located in the zone UTC+1, so my handheld selected UTC+1 automatically, and I had to correct it manually to UTC+0 to have the real local time.
(I didn't go there.) On my antiquated MacBook, if I display the timezone map and click on what appears to be the correct location, it says: Time Zone: GMT+00:00 Las Palmas de Gran Canaria, GC - Spain But your service provider may be based in Portugal. -- gil
Paul Gilmartin wrote:
On 2019-02-28, at 10:29:35, Martin Burnicki wrote:
For example, I've visited the Canary Islands located in the Atlantic, in zone UTC+0, but these islands belong to Spain which is located in the zone UTC+1, so my handheld selected UTC+1 automatically, and I had to correct it manually to UTC+0 to have the real local time.
(I didn't go there.)
On my antiquated MacBook, if I display the timezone map and click on what appears to be the correct location, it says: Time Zone: GMT+00:00 Las Palmas de Gran Canaria, GC - Spain
Of course, with ma Linux Laptop I can do this in the same way. However, the topic to which I replied was an automatic selection of the time zone by a handheld, and there are at least 2 ways to find it out: 1.) via the built-in GNSS receiver which determines the geographic position, and you need a map to see to which time zone this position belongs 2.) via the telecom network, which also seems to broadcast time zone information. My smartphone used the latter, and it failed since my location was on an island in UTC+0, but politically this belongs to Spain, which is UTC+1, so the telecom network seems to broadcast UTC+1, which is obviously wrong since the public clocks on that island also showed the time for UTC+0. So IMO any automatic procedure is good as long as you can override it manually. ;-) Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy
On 2/25/19 2:32 AM, Martin Burnicki wrote:
If the current time zone names should indeed just be taken as IDs rather than real names then IMO it would be very helpful if there also was a list of mappings provided that links readable display names to TZDB ID names.
tzdb provides this in its combination of the files zone1970.tab and iso3166.tab, the latter useful if the former simply lists country codes. For example, zone1970.tab maps America/Porto_Velho to "Rondônia" (since the country of Brazil has multiple timezones), and maps Europe/Prague to CZ,SK which iso3166.tab in turn maps to "Czech Republic" and "Slovakia" (since this timezone has multiple countries). The tzdb files support only American English; as Tony mentioned, for other locales CLDR is the way to go.
For example, the zone "Europe/Macedonia" is displayed as "Europa/Makedonien" on my Linux/KDE system set to German language. That's odd, as tzdb has no zone named "Europe/Macedonia". North Macedonia is currently represented by Europe/Belgrade. If tzdb had a timezone named "Europe/Macedonia", we'd have to worry about renaming it to "Europe/North_Macedonia" now.
Perhaps the strings "Europe/Macedonia" and "Europa/Makedonien" are part of the KDE user interface to tzdb; if so, KDE will need to deal with the country's recent renaming.
Paul Eggert wrote:
On 2/25/19 2:32 AM, Martin Burnicki wrote:
If the current time zone names should indeed just be taken as IDs rather than real names then IMO it would be very helpful if there also was a list of mappings provided that links readable display names to TZDB ID names.
tzdb provides this in its combination of the files zone1970.tab and iso3166.tab, the latter useful if the former simply lists country codes. For example, zone1970.tab maps America/Porto_Velho to "Rondônia" (since the country of Brazil has multiple timezones), and maps Europe/Prague to CZ,SK which iso3166.tab in turn maps to "Czech Republic" and "Slovakia" (since this timezone has multiple countries).
The tzdb files support only American English; as Tony mentioned, for other locales CLDR is the way to go.
OK, but for "normal" users or even developers this may still be confusing enough. ;-)
For example, the zone "Europe/Macedonia" is displayed as "Europa/Makedonien" on my Linux/KDE system set to German language. That's odd, as tzdb has no zone named "Europe/Macedonia". North Macedonia is currently represented by Europe/Belgrade. If tzdb had a timezone named "Europe/Macedonia", we'd have to worry about renaming it to "Europe/North_Macedonia" now.
While "Europa/Makedonien" is shown in KDE, "Europe/Macedonia" comes from tzselect: $ tzselect Please identify a location so that time zone rules can be set correctly. Please select a continent or ocean. 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) none - I want to specify the time zone using the Posix TZ format. #? 8 Please select a country. 1) Aaland Islands 18) Greece 35) Norway 2) Albania 19) Guernsey 36) Poland 3) Andorra 20) Hungary 37) Portugal 4) Austria 21) Ireland 38) Romania 5) Belarus 22) Isle of Man 39) Russia 6) Belgium 23) Italy 40) San Marino 7) Bosnia & Herzegovina 24) Jersey 41) Serbia 8) Britain (UK) 25) Latvia 42) Slovakia 9) Bulgaria 26) Liechtenstein 43) Slovenia 10) Croatia 27) Lithuania 44) Spain 11) Czech Republic 28) Luxembourg 45) Sweden 12) Denmark 29) Macedonia 46) Switzerland 13) Estonia 30) Malta 47) Turkey 14) Finland 31) Moldova 48) Ukraine 15) France 32) Monaco 49) Vatican City 16) Germany 33) Montenegro 17) Gibraltar 34) Netherlands #? 29 The following information has been given: Macedonia Therefore TZ='Europe/Skopje' will be used. Local time is now: Tue Feb 26 09:18:33 CET 2019. Universal Time is now: Tue Feb 26 08:18:33 UTC 2019.
Perhaps the strings "Europe/Macedonia" and "Europa/Makedonien" are part of the KDE user interface to tzdb; if so, KDE will need to deal with the country's recent renaming.
I'm not sure if KDE uses CLDR or whatever, but from a pure user/developer's point of view I think there is still room for improvement to yield consistent information presented in the user interfaces. That would also avoid discussions as with the ID name for Ukraine, or the new liberland time just requested by a user. I'm aware that is really complex stuff, though. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy
On Feb 26, 2019, at 12:50 AM, Martin Burnicki <martin.burnicki@meinberg.de> wrote:
While "Europa/Makedonien" is shown in KDE, "Europe/Macedonia" comes from tzselect:
That's "Macedonia" as an item in tzselect, under the continent of Europe, in the tzselect script (rather than "Europe/Macedonia" as a string). That means it comes from the iso3166.tab file (which now says "North Macedonia"). For which of the languages with entries in ISO 639 are you suggesting that the tzdb maintainers supply translations of that file?
Guy Harris wrote:
On Feb 26, 2019, at 12:50 AM, Martin Burnicki <martin.burnicki@meinberg.de> wrote:
While "Europa/Makedonien" is shown in KDE, "Europe/Macedonia" comes from tzselect:
That's "Macedonia" as an item in tzselect, under the continent of Europe, in the tzselect script (rather than "Europe/Macedonia" as a string).
That means it comes from the iso3166.tab file (which now says "North Macedonia").
For which of the languages with entries in ISO 639 are you suggesting that the tzdb maintainers supply translations of that file?
There are no specific cases. I just saw that the time zone and time zone name handling in different user interfaces is sometimes very different, and if you select a specific setting on different systems you can't even be sure that you get the same results, e.g. regarding DST settings. So I thought this might be a way to make the handling more consistent and less confusing for users with even less experience with tzdb than I have myself. ;-) Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy
On Feb 26, 2019, at 1:53 AM, Martin Burnicki <martin.burnicki@meinberg.de> wrote:
I just saw that the time zone and time zone name handling in different user interfaces is sometimes very different, and if you select a specific setting on different systems you can't even be sure that you get the same results, e.g. regarding DST settings.
The right way to do the UI is the way Apple and Ubuntu do it - *no* UI, if possible (selection based on location, although I don't know whether Ubuntu does that), and, in situations where that's not possible, a UI that lets you either pick locations on a map, if your system has a GUI, or mention a name for your location, such as a city/town/village or, if you're in a location that has no cities/towns/villages, some other name such as "Liberland". The latter is what should be done even for the command line, e.g. $ `tzenv München` date Tue Feb 26 19:46:08 CET 2019 # or with translated day and month names, and zone abbreviation or # setzone Paris or # setzone "Paris, Texas" if you're *not* in the City of Light. (Whether disambiguation is needed even for the best-known instance of a city name is an issue for discussion.)
So I thought this might be a way to make the handling more consistent and less confusing for users with even less experience with tzdb than I have myself. ;-)
Ultimately, the vast majority of users should have no more experience with tzdb than with compilers for the programming languages in which their OS is written or with the circuit design of the processors their system uses, i.e. none. tzdb shouldn't be part of the UI, it should be, for most users, a hidden implementation detail.
I don't think localizing the identifier would solve much of the problem like user at Hanoi would most probably not know they need to select Asia/Bangkok to be the right timezone for them even if you localize the identifier. 在 2019年2月25日週一 18:32，Martin Burnicki <martin.burnicki@meinberg.de> 寫道：
Sorry for jumping in so late. I've been on a short vacation with very limited internet access, and have just read the emails in this thread.
If the current time zone names should indeed just be taken as IDs rather than real names then IMO it would be very helpful if there also was a list of mappings provided that links readable display names to TZDB ID names.
Otherwise each project has to do this by itself, and the problem seems to be that some projects just use the ID names from TZDB while other projects do the mapping by themselves.
If there was a mapping list included with TZDB then different projects could rely to them and use the same, consistent information and displaying.
Anyway, there's still a different point. I'm assuming that English is the native language for most members of this list, but most applications taking care about time zones let users select them zone in their native language, so some internationalization would also be very helpful.
For example, the zone "Europe/Macedonia" is displayed as "Europa/Makedonien" on my Linux/KDE system set to German language. As far as I can see each project that has to deal with this kind of things has to provide the translations by themselves.
Since TZDB is maintained on github I'd expect there would be quite some folks that were happy to provide translations for zone names, eventually exported from their own, local projects.
Once such a mapping list has been set up it should not be to hard to maintain it, and those who make changes to the DB itself know best which of the mapped links would be affected by a particular change.
Another point that has recently been discussed is how an event time is affected if the time zone rules change after the point in time where the event is created for some local time, and before the time the event happens.
I think we'd have too distinguish a little bit. If there is a virtual meeting scheduled in local time for 11:30 New York time, and the New York time zone changes by 1 hour then I'd expect that the event time will still be 11:30 local time, but the event time for my location in Central Europe will change by 1 hour.
On the other hand, if I've booked a flight for 11:30 New York time and the New York time zone changes then eventually the departure time may also change by 1 hour to keep the flight consistent with connection flights in other time zones.
So it depends on the application, but in any case it would be helpful if at least the time zone names on my PC, on my smartphone, etc. would be consistent.
Martin -- Martin Burnicki
Senior Software Engineer
MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/
Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy
Phake Nick wrote:
I don't think localizing the identifier would solve much of the problem like user at Hanoi would most probably not know they need to select Asia/Bangkok to be the right timezone for them even if you localize the identifier.
Sorry, you misunderstood what I wrote. As I already wrote in another reply I just meant that the names presented in the user interface should be localized. Obviously this is sometimes the case, sometimes not, and sometimes in a different way, and it would be good to make it easier or more obvious to show consistent information to a user. For example, people living in Liberland may not appreciate very much that they have to select a timezone Europe/Belgrade just because Liberland is located at the same longitude, and happens to use the same DST settings as Europe/Belgrade. So it would be sufficient to add Liberland to CLDR or whatever provides a mapping, so that Liberland can be selected for the time zone settings, and this is the label that should be localized. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy
On 26/02/2019 08:59, Martin Burnicki wrote:
So it would be sufficient to add Liberland to CLDR or whatever provides a mapping, so that Liberland can be selected for the time zone settings, and this is the label that should be localized.
That is essentially how it has always been documented. Localizations should take care of any 'contentious' stuff anyway and in addition nowadays this needs to take care of flagging where pre 1970's data may be wrong ... -- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
Yes! On 2/26/19 10:59 AM, Martin Burnicki wrote:
Phake Nick wrote:
I don't think localizing the identifier would solve much of the problem like user at Hanoi would most probably not know they need to select Asia/Bangkok to be the right timezone for them even if you localize the identifier. Sorry, you misunderstood what I wrote.
As I already wrote in another reply I just meant that the names presented in the user interface should be localized. Obviously this is sometimes the case, sometimes not, and sometimes in a different way, and it would be good to make it easier or more obvious to show consistent information to a user.
For example, people living in Liberland may not appreciate very much that they have to select a timezone Europe/Belgrade just because Liberland is located at the same longitude, and happens to use the same DST settings as Europe/Belgrade.
So it would be sufficient to add Liberland to CLDR or whatever provides a mapping, so that Liberland can be selected for the time zone settings, and this is the label that should be localized.
Martin
On Feb 25, 2019, at 2:32 AM, Martin Burnicki <martin.burnicki@meinberg.de> wrote:
If the current time zone names should indeed just be taken as IDs rather than real names then IMO it would be very helpful if there also was a list of mappings provided that links readable display names to TZDB ID names.
Readable display names of what? I'm not sure what sort of name a tzdb region should have. tzdb regions can cross national boundaries, or can correspond to subregions of a nation or subdivision of a nation (such as a "state" in some English-speaking countries such as the US and Australia or as translated to English in some other countries such as Mexico, Germany, and Brazil, or a "province" in Canada). The tzdb project might have to *pick* a display name for some tzdb regions. and I suspect many involved with the project would *really* prefer that the project *not* do so - that would open it up to the same complaints some express about tzdb IDs now. And I'm not even convinced that users want to care about tzdb regions; those regions don't completely correspond to, for example, what people call "time zones" in the US, so "Mountain time" or "Mountain time zone" doesn't correspond to the America/Denver tzdb region - Arizona is in the "Mountain" time zone, but it hasn't done standard/summar time switching since 1968, unlike other parts of that time zone. What I suspect users want is to have clock time work appropriately for their location; if doing so doesn't involve knowing or caring about the details of the tzdb, so much the better. And, in fact, that works pretty well on my Mac and iPhone. They're currently set up to use their mechanisms to determine the current longitude and latitude of the machine ("Core Location", which can use GPS on iPhones that have it, and can use other mechanisms such as known locations of mobile telephony cells and Wi-Fi access points on machines lacking GPS) to pick the tzdb region; if that's disabled, then, at least on the Mac, I can pick a location on a map, or type the name of a city into a text box, to select the tzdb region. The city does *NOT* have to be the city used in the tzdb region's name. And when I say "current longitude and latitude of the machine", I mean that if its location changes, the current time zone changes. When I traveled from California to Pennsylvania a few years ago, the time zone switched, and it switched back when I returned. *That* required not only Core Location, to determine my location, but also required a mechanism to deliver notifications to *all* processes (not just processes running written-for-macOS GUI programs, but UN*X programs that just use localtime() or time()) that the time zone has changed. That's buried in the C library, so that if you run this program: #include <stdio.h> #include <time.h> #include <unistd.h> int main(void) { for (;;) { time_t now; now = time(NULL); printf("%s", ctime(&now)); sleep(600); } } it will, if you move from one time zone to another, switch from the old time zone to the new time zone when displaying the time.
Otherwise each project has to do this by itself, and the problem seems to be that some projects just use the ID names from TZDB while other projects do the mapping by themselves.
If there was a mapping list included with TZDB then different projects could rely to them and use the same, consistent information and displaying.
If there was a generally-available mapping mechanism, whether it's included with the tzdb or not, then different projects could rely on it and use the same, consistent information and displaying. And it appears there is such a mechanism. The GeoNames project: https://www.geonames.org records information about a lot of locations, *including* tzdb ID information. They offer a number of Web services: https://www.geonames.org/export/web-services.html including one to look up the tzdb region (and some other information) for a given longitude and latitude: http://www.geonames.org/export/web-services.html#timezone It has other services to look up cities, getting the longitude and latitude and, I think, to find cities within a given area. They list on their About page: https://www.geonames.org/about.html both "Apple Snowleopard" and Ubuntu as uses of the data base; I don't know whether macOS or iOS use it for their tzdb region selection, but Ubuntu have their own Web service used in *its* time zone selector UI: https://launchpad.net/ubuntu-geonames which I think uses the GeoNames database, periodically downloading it and generating their own database (so as not to burden the GeoNames service).
Anyway, there's still a different point. I'm assuming that English is the native language for most members of this list, but most applications taking care about time zones let users select them zone in their native language, so some internationalization would also be very helpful.
For example, the zone "Europe/Macedonia" is displayed as "Europa/Makedonien" on my Linux/KDE system set to German language.
"Europe/Macedonia" is not a tzdb ID and, as far s I know, never has been. The ID for the tzdb region that includes North Macedonia is Europe/Belgrade; for historical reasons, there is a historical link from Europe/Skopje to Europe/Belgrade. Therefore, it's not as if the tzdb hasn't internationalized something here - the tzdb didn't supply Europe/Macedonia in the first place, some other entity did, and you should ask *them* to internationalize it - or ask them to use the CLDR: http://cldr.unicode.org
Guy Harris <guy@alum.mit.edu> wrote:
And I'm not even convinced that users want to care about tzdb regions; those regions don't completely correspond to, for example, what people call "time zones" in the US, so "Mountain time" or "Mountain time zone" doesn't correspond to the America/Denver tzdb region - Arizona is in the "Mountain" time zone, but it hasn't done standard/summar time switching since 1968, unlike other parts of that time zone.
What I suspect users want is to have clock time work appropriately for their location; if doing so doesn't involve knowing or caring about the details of the tzdb, so much the better.
Up to a point... A common cause of significant confusion is when people are trying to organize meetings between people in multiple time zones. I think the confusion is due to poor calendaring data models which make it difficult to provide a user interface that illustrates what is going on. (old long version of these thoughts: https://fanf.livejournal.com/104586.html) The key point is to attach one or more locations to an event. The system needs to be able to look up which timezone applies to which locations; there are ways to make that easyq. One of the locations is the primary location, and the event's scheduled time is local time at that location; the secondary locations allow users to easily see what time it is for all the participants, so they don't accidentally schedule something for 05:00. And it allows the system to automatically flag up weirdnesses that happen in March or October or when TZs change. In particular it's easy to find out when TZ changes have effects that matter to meeting schedules without false positives. And if the primary UI is location, not TZ, there's less likelihood of idiocies like Microsoft Exchange saying the time in Cambridge in July is GMT. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ Northwest Hebrides, Southeast Bailey: Southwesterly becoming cyclonic, 4 or 5. Very rough, becoming rough. Rain. Moderate, occasionally poor.
On Feb 26, 2019, at 10:17 AM, Tony Finch <dot@dotat.at> wrote:
Guy Harris <guy@alum.mit.edu> wrote:
And I'm not even convinced that users want to care about tzdb regions; those regions don't completely correspond to, for example, what people call "time zones" in the US, so "Mountain time" or "Mountain time zone" doesn't correspond to the America/Denver tzdb region - Arizona is in the "Mountain" time zone, but it hasn't done standard/summar time switching since 1968, unlike other parts of that time zone.
What I suspect users want is to have clock time work appropriately for their location; if doing so doesn't involve knowing or caring about the details of the tzdb, so much the better.
Up to a point...
A common cause of significant confusion is when people are trying to organize meetings between people in multiple time zones. I think the confusion is due to poor calendaring data models which make it difficult to provide a user interface that illustrates what is going on.
... None of which appears to require that the *end users* - including the meeting organizer(s) - know or care about the details of the tzdb. They may need to know that scheduling the meeting for thus-and-such a time in London means scheduling it for 03:00 at some other location, so, if they schedule for that time, somebody's going to have to wake up early or go to sleep late, but that's what the software would do.
Guy Harris wrote:
On Feb 26, 2019, at 10:17 AM, Tony Finch <dot@dotat.at> wrote:
Guy Harris <guy@alum.mit.edu> wrote:
And I'm not even convinced that users want to care about tzdb regions; those regions don't completely correspond to, for example, what people call "time zones" in the US, so "Mountain time" or "Mountain time zone" doesn't correspond to the America/Denver tzdb region - Arizona is in the "Mountain" time zone, but it hasn't done standard/summar time switching since 1968, unlike other parts of that time zone.
What I suspect users want is to have clock time work appropriately for their location; if doing so doesn't involve knowing or caring about the details of the tzdb, so much the better.
Up to a point...
A common cause of significant confusion is when people are trying to organize meetings between people in multiple time zones. I think the confusion is due to poor calendaring data models which make it difficult to provide a user interface that illustrates what is going on.
...
None of which appears to require that the *end users* - including the meeting organizer(s) - know or care about the details of the tzdb. They may need to know that scheduling the meeting for thus-and-such a time in London means scheduling it for 03:00 at some other location, so, if they schedule for that time, somebody's going to have to wake up early or go to sleep late, but that's what the software would do.
Anyway, it would be a nice feature to let the user see what was automatically selected, and if this is plausible. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy
On Feb 28, 2019, at 2:22 AM, Martin Burnicki <martin.burnicki@meinberg.de> wrote:
Anyway, it would be a nice feature to let the user see what was automatically selected, and if this is plausible.
The macOS time zone selector draws a world map, showing the "time zone", in the "what you see on those time zone maps" sense, with a red pin at your location, and giving the name of your current time (e.g., Pacific Standard Time, as we're not on summer time) and of the closest city.
Guy Harris wrote:
On Feb 28, 2019, at 2:22 AM, Martin Burnicki <martin.burnicki@meinberg.de> wrote:
Anyway, it would be a nice feature to let the user see what was automatically selected, and if this is plausible.
The macOS time zone selector draws a world map, showing the "time zone", in the "what you see on those time zone maps" sense, with a red pin at your location, and giving the name of your current time (e.g., Pacific Standard Time, as we're not on summer time) and of the closest city.
A map is fine as long as you see one. ;-) If there is no map then a plausible location name would be good. For example, I'm in Germany and usually the displayed location name is Europe/Berlin, and (at least for current zone rules) it wouldn't make much difference when I selected Europe/{Stockholm|Oslo|Amsterdam|Paris}. However, folks who are not so familiar with this kind of stuff would probably be confused if they see Stockholm instead of Berlin for their time zone. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy
On Mar 1, 2019, at 1:07 AM, Martin Burnicki <martin.burnicki@meinberg.de> wrote:
A map is fine as long as you see one. ;-)
If there is no map then a plausible location name would be good.
As I said: ...and giving the name of your current time (e.g., Pacific Standard Time, as we're not on summer time) and of the closest city.
For example, I'm in Germany and usually the displayed location name is Europe/Berlin,
Even if you're in Düsseldorf or Hamburg or Munich or...? If so, why? (You said "location name", not "tzdb ID", so "because that's the tzdb ID for my location" isn't a valid answer.)
and (at least for current zone rules) it wouldn't make much difference when I selected Europe/{Stockholm|Oslo|Amsterdam|Paris}. However, folks who are not so familiar with this kind of stuff would probably be confused if they see Stockholm instead of Berlin for their time zone.
Somebody in Sweden who's not so familiar with this kind of stuff would probably be confused if they see Stockholm? And they wouldn't be confused if they saw Berlin? If so, why? Or do you mean somebody in *Germany* who's not so familiar with this kind of stuff would probably be confused if they see Stockholm, in which case the next question is "so why would you show Stockholm to somebody in Germany?" - just as "so why would you show Berlin to somebody in Sweden?" is also a good question. For that matter, given that I'm several hundred km away from Los Angeles, why should I be shown Los Angeles? Hint: "because that's what the Theory file says" isn't a reasonable answer for a program intended for general users rather than tzdb nerds.
Guy Harris wrote:
On Mar 1, 2019, at 1:07 AM, Martin Burnicki <martin.burnicki@meinberg.de> wrote:
A map is fine as long as you see one. ;-)
If there is no map then a plausible location name would be good.
As I said:
...and giving the name of your current time (e.g., Pacific Standard Time, as we're not on summer time) and of the closest city.
For example, I'm in Germany and usually the displayed location name is Europe/Berlin,
Even if you're in Düsseldorf or Hamburg or Munich or...? If so, why? (You said "location name", not "tzdb ID", so "because that's the tzdb ID for my location" isn't a valid answer.)
With "location name" I just meant mean what is displayed to the ordinary user, which eventually is even localized. For users in Germany Düsseldorf, Hamburg, Munich or Berlin is fine, but Stockholm probably not since users are not sure if Stockholm has the same TZ rules as Germany.
and (at least for current zone rules) it wouldn't make much difference when I selected Europe/{Stockholm|Oslo|Amsterdam|Paris}. However, folks who are not so familiar with this kind of stuff would probably be confused if they see Stockholm instead of Berlin for their time zone.
Somebody in Sweden who's not so familiar with this kind of stuff would probably be confused if they see Stockholm? And they wouldn't be confused if they saw Berlin?
If so, why?
Or do you mean somebody in *Germany* who's not so familiar with this kind of stuff would probably be confused if they see Stockholm, in which case the next question is "so why would you show Stockholm to somebody in Germany?" - just as "so why would you show Berlin to somebody in Sweden?" is also a good question.
Yes, I meant somebody in Germany. Of course for users in Sweden this would be fine, but Berlin would be confusing.
For that matter, given that I'm several hundred km away from Los Angeles, why should I be shown Los Angeles? Hint: "because that's what the Theory file says" isn't a reasonable answer for a program intended for general users rather than tzdb nerds.
I don't think the distance matters much. For folks in a different state in the USA than actually shown in their settings this might be confusing as well, if they are not sure if both states have the same TZ rules. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy
On Mar 1, 2019, at 2:41 AM, Martin Burnicki <martin.burnicki@meinberg.de> wrote:
With "location name" I just meant mean what is displayed to the ordinary user, which eventually is even localized.
For users in Germany Düsseldorf, Hamburg, Munich or Berlin is fine, but Stockholm probably not since users are not sure if Stockholm has the same TZ rules as Germany.
Well, that pretty much shows that tzdb IDs are not the right answer, given that users might not know that, for example, Hanoi has (since 1970) the same offset and summer time rules as Bangkok. It even says that mapping from a tzdb ID to something "more friendly" won't work in those cases. So, if a user really wants to know what time zone rules are being invoked at the current location, we need a way to describe them that wouldn't be meaningless noise to a user, e.g. {name} summer time rules with {name} being the name of an appropriate region - probably including the country you're currently in, but that isn't sufficient in many cases - and "summer time rules" appropriately localized, e.g. "Daylight Saving Time rules" in the US. {name}, as indicated above, is not something that can be looked up in a table given only a tzdb ID; you'd also need some indication of your physical location, so you'd get German summer time rules in Berlin, Düsseldorf, Hamburg, Munich, etc. and Swedish summer time rules in Stockholm, Gothenburg, Uppsala, etc., and so on. Or you could just dump out the rules - but one of the good things about the tzdb is that it reduces the chances that you need to *know* the rules, so dumping out the rules might be telling the user something they don't know and don't even want to know.
Guy Harris wrote:
On Mar 1, 2019, at 2:41 AM, Martin Burnicki <martin.burnicki@meinberg.de> wrote:
With "location name" I just meant mean what is displayed to the ordinary user, which eventually is even localized.
For users in Germany Düsseldorf, Hamburg, Munich or Berlin is fine, but Stockholm probably not since users are not sure if Stockholm has the same TZ rules as Germany.
Well, that pretty much shows that tzdb IDs are not the right answer, given that users might not know that, for example, Hanoi has (since 1970) the same offset and summer time rules as Bangkok. It even says that mapping from a tzdb ID to something "more friendly" won't work in those cases.
That's what I'm trying to say all the time. ;-)
So, if a user really wants to know what time zone rules are being invoked at the current location, we need a way to describe them that wouldn't be meaningless noise to a user, e.g.
{name} summer time rules
with {name} being the name of an appropriate region - probably including the country you're currently in, but that isn't sufficient in many cases - and "summer time rules" appropriately localized, e.g. "Daylight Saving Time rules" in the US.
I fully agree. This would be very helpful. For example, in earlier Windows versions (since Windows NT) there was only a single DST rule for a particular zone, and there was not even a way for an ordinary user to find out *when* DST would start and end for the zone he had selected. You could only find this out if you looked into the registry and tried to interpret the values correctly. This is why the monitor program we (Meinberg) ship with the driver software for our PCI cards on Windows (since Windows NT) has a tab that shows these Windows-specific settings, so a user can check if the settings are as expected, and the system will switch to or from DST at the correct instance.
{name}, as indicated above, is not something that can be looked up in a table given only a tzdb ID; you'd also need some indication of your physical location, so you'd get
German summer time rules
in Berlin, Düsseldorf, Hamburg, Munich, etc. and
Swedish summer time rules
in Stockholm, Gothenburg, Uppsala, etc., and so on.
Or you could just dump out the rules - but one of the good things about the tzdb is that it reduces the chances that you need to *know* the rules, so dumping out the rules might be telling the user something they don't know and don't even want to know.
Yes, and I think this should me enforced more by making the "ID name" less readable, so developers can see that they must not use them directly but do some mapping before. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy
On 3/1/19 3:05 AM, Guy Harris wrote:
if a user really wants to know what time zone rules are being invoked at the current location, we need a way to describe them that wouldn't be meaningless noise to a user, e.g.
{name} summer time rules
with {name} being the name of an appropriate region - probably including the country you're currently in, but that isn't sufficient in many cases - and "summer time rules" appropriately localized, e.g. "Daylight Saving Time rules" in the US.
If this descriptive string is intended to summarize a tzdb Zone without giving full details, then zone1970.tab is one attempt to do that. For example, for Asia/Bangkok it gives "Indochina (most areas)", and for Europe/Berlin it gives "Germany (most areas)". As you mention, a string that fully described a Zone would contain so much detail that users would be overwhelmed. So there's a judgment call as to how much detail to put into the string. zone1970.tab's strings currently do not contain substrings like "summer time rules", partly to avoid churn (for example, we won't have to change zone1970.tab merely if Germany cancels DST) and partly because I thought the detail to be overkill for many users. CLDR and/or other groups that localize zone1970.tab (or its equivalent) might find it useful to put more detail into their strings, depending on the circumstances.
Tony, Tony Finch wrote:
A common cause of significant confusion is when people are trying to organize meetings between people in multiple time zones. I think the confusion is due to poor calendaring data models which make it difficult to provide a user interface that illustrates what is going on.
(old long version of these thoughts: https://fanf.livejournal.com/104586.html)
Thanks for the pointer. I haven't seen your article before, but it is really a great summary of the problems I've also observed. Martin -- Martin Burnicki Senior Software Engineer MEINBERG Funkuhren GmbH & Co. KG Email: martin.burnicki@meinberg.de Phone: +49 5281 9309-414 Linkedin: https://www.linkedin.com/in/martinburnicki/ Lange Wand 9, 31812 Bad Pyrmont, Germany Amtsgericht Hannover 17HRA 100322 Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung Websites: https://www.meinberg.de https://www.meinbergglobal.com Training: https://www.meinberg.academy
On 26/02/2019 18:17, Tony Finch wrote:
(old long version of these thoughts:https://fanf.livejournal.com/104586.html) Nothing much has changed in ten years :(
-- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
On 2019-02-26 11:17, Tony Finch wrote:
Guy Harris wrote:
And I'm not even convinced that users want to care about tzdb regions; those regions don't completely correspond to, for example, what people call "time zones" in the US, so "Mountain time" or "Mountain time zone" doesn't correspond to the America/Denver tzdb region - Arizona is in the "Mountain" time zone, but it hasn't done standard/summar time switching since 1968, unlike other parts of that time zone.
What I suspect users want is to have clock time work appropriately for their location; if doing so doesn't involve knowing or caring about the details of the tzdb, so much the better. Up to a point... A common cause of significant confusion is when people are trying to organize meetings between people in multiple time zones. I think the confusion is due to poor calendaring data models which make it difficult to provide a user interface that illustrates what is going on. (old long version of these thoughts: https://fanf.livejournal.com/104586.html) The key point is to attach one or more locations to an event. The system needs to be able to look up which timezone applies to which locations; there are ways to make that easyq. One of the locations is the primary location, and the event's scheduled time is local time at that location; the secondary locations allow users to easily see what time it is for all the participants, so they don't accidentally schedule something for 05:00. And it allows the system to automatically flag up weirdnesses that happen in March or October or when TZs change. In particular it's easy to find out when TZ changes have effects that matter to meeting schedules without false positives. And if the primary UI is location, not TZ, there's less likelihood of idiocies like Microsoft Exchange saying the time in Cambridge in July is GMT.
With conference calls, often an organizer will be unaware of parties' locations, so client confirmations need to feed back locations which the organizer's client can record as supplementary locations with associated supplementary time zones. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised.
participants (22)
-
Alan Mintz -
Brian Inglis -
Clive D.W. Feather -
filip -
Fred Gleason -
Guy Harris -
Hans-Joerg Happel -
John Hawkinson -
Lester Caine -
Martin Burnicki -
Michael Douglass -
Michael H Deckers -
Paul Eggert -
Paul Gilmartin -
Paul.Koning＠dell.com -
Phake Nick -
Philip Paeps -
Steffen Nurpmeso -
Stephen Colebourne -
Steve Allen -
Tim Parenti -
Tony Finch