Introduce Etc/UTC+x timezones?
Hi, If people are aware of timezones, they often know UTC and their offsets (e.g. Europe/Berlin is UTC+2 summer). But they are probably not aware that the Etc/GMT offsets are inverted (e.g. you have to select Etc/GMT-2 for UTC+2). I was not aware of that and other people as well as the bugs in Ubuntu and Debian indicate (see https://launchpad.net/bugs/1325949 and https://bugs.debian.org/540305). What do you think about the idea of introducing Etc/UTC+x timezones that have the "correct" offset so that people can select fixed offsets more easily? So Etc/GMT-2 would be renamed to Etc/UTC+2 and Etc/GMT-2 would become a symlink to it (same for all other Etc/GMT+x and Etc/GMT-x timezones). -- Benjamin Drung Debian & Ubuntu Developer
Date: Fri, 21 Apr 2023 15:32:19 +0200 From: Benjamin Drung via tz <tz@iana.org> Message-ID: <e56611ce5f328ac88ca0b902ac77c8fa10d3a3b7.camel@canonical.com> | So Etc/GMT-2 would be renamed to Etc/UTC+2 and Etc/GMT-2 would | become a symlink to it GMT+2 and GMT-2 already both exist, they just (for historical reasons) mean the opposite of the current standard way of writing time offsets. $ TZ=Etc/GMT+2 date; date -u; TZ=Etc/GMT-2 date Fri Apr 21 14:47:33 -02 2023 Fri Apr 21 16:47:33 UTC 2023 Fri Apr 21 18:47:33 +02 2023 It is the same with POSIX standard TZ settings (as defined now) TZ=UTC-2 is in Europe, TZ=UTC+2 is somewhere in the Atlantic. Nothing can really be done about this -- though I guess we could have a whole new set of timezones, like Etc but with the signs reversed. like TZ=Std/GMT+2 TZ=Std/UTC-4 or something -- perhaps ISO instead of Std as ISO8601 (or whatever number it is) uses the opposite sign for the offset from UTC than POSIX does. Whether that would make things more, or less, confusing, I have no idea. kre
On 2023-04-21 06:32, Benjamin Drung via tz wrote:
What do you think about the idea of introducing Etc/UTC+x timezones that have the "correct" offset so that people can select fixed offsets more easily?
Wouldn't this introduce confusion? Etc/UTC+2 would mean the opposite of Etc/GMT+2. We can't get rid of the latter name, due to backward compatibility. Furthermore, Etc/UTC+2 would magnify Etc/GMT+2's problem, in that it would tempt people into writing TZ='UTC+2' which is just wrong. The bug reports you cited don't seem to be instances of user confusion with tzdata, only of frustration that dpkg-reconfigure presents these wrong-signed names to the user. However, those names are meant for internal use, just as the other Zone names are. So the real bug here seems to be with dpkg-reconfigure, not with tzdata. In contrast, tzselect gets this right: it does not expose names like Etc/GMT+2 to the user.
On 21 April 2023 17:59:38 BST, Paul Eggert via tz <tz@iana.org> wrote:
On 2023-04-21 06:32, Benjamin Drung via tz wrote:
What do you think about the idea of introducing Etc/UTC+x timezones that have the "correct" offset so that people can select fixed offsets more easily?
Wouldn't this introduce confusion? Etc/UTC+2 would mean the opposite of Etc/GMT+2. We can't get rid of the latter name, due to backward compatibility. Furthermore, Etc/UTC+2 would magnify Etc/GMT+2's problem, in that it would tempt people into writing TZ='UTC+2' which is just wrong.
The bug reports you cited don't seem to be instances of user confusion with tzdata, only of frustration that dpkg-reconfigure presents these wrong-signed names to the user. However, those names are meant for internal use, just as the other Zone names are. So the real bug here seems to be with dpkg-reconfigure, not with tzdata.
In contrast, tzselect gets this right: it does not expose names like Etc/GMT+2 to the user.
In PHP we actively discourage people using these Etc/GMT zones, as they're not actually zones, but fixed offsets . They're often just temporary place holders for the offset at some time during the year. And we're of the opinion that they shouldn't be used in user facing interfaces at all. cheers Derick
On 4/21/23 13:12:21, Derick Rethans via tz wrote:
In PHP we actively discourage people using these Etc/GMT zones, as they're not actually zones, but fixed offsets . They're often just temporary place holders for the offset at some time during the year. And we're of the opinion that they shouldn't be used in user facing interfaces at all.
Be practical. Suppose I and colleagues in Canberra want to arrange a series of E-conferences at mutually convenient tines. How should I describe my timezone: MST7MDT,M3.2.0,M11.1.0? /America/Denver? 40°00′54″N 105°16′14″W? ... ? what tools should I assume they have? -- gil
On Apr 21, 2023, at 12:45 PM, Paul Gilmartin via tz <tz@iana.org> wrote:
On 4/21/23 13:12:21, Derick Rethans via tz wrote:
In PHP we actively discourage people using these Etc/GMT zones, as they're not actually zones, but fixed offsets . They're often just temporary place holders for the offset at some time during the year. And we're of the opinion that they shouldn't be used in user facing interfaces at all.
Be practical. Suppose I and colleagues in Canberra want to arrange a series of E-conferences at mutually convenient tines. How should I describe my timezone: MST7MDT,M3.2.0,M11.1.0? /America/Denver? 40°00′54″N 105°16′14″W? ... ?
If they have tools that support a proper UI for selecting tzdb regions, tell them your location and, if the UI doesn't recognize Suffolk, Montana or wherever you are, give them the location of a nearby city large enough to be notable. Otherwise, either: If all of the conferences will take place when Daylight Saving Time is in effect in the US, describe it as "currently, 6 hours west of UTC". If all of the conferences will take place when Daylight Saving Time is not in effect in the US, describe it as "currently, 7 hours west of UTC". If some will take place when it's in effect and some won't, describe it as "currently, 6 hours west of UTC, but after 2023-11-04, it will be 7 hours west of UTC". or, if they have tools that support a crappy UI that exposes tzids, give them America/Denver, ask them what software they're using, and complain to the vendor of the software that they should do a better job. (There are various projects that can help, such as OpenStreetMap and the "shape files of tzdb regions" project, but it'd be nice if there were easier ways for tzdb users to find and use them.)
what tools should I assume they have?
Either 1) the ones that they said they have when you asked them or 2) just their appointment calendars.
On 4/21/23 16:02:58, Guy Harris wrote:
Be practical. Suppose I and colleagues in Canberra want to arrange a series of E-conferences at mutually convenient tines. How should I describe my timezone: MST7MDT,M3.2.0,M11.1.0? /America/Denver? 40°00′54″N 105°16′14″W? ... ?
If they have tools that support a proper UI for selecting tzdb regions, tell them your location and, if the UI doesn't recognize Suffolk, Montana or wherever you are, give them the location of a nearby city large enough to be notable. ... Then I thought my Contact card is a reasonable place to keep this. So: <https://datatracker.ietf.org/doc/html/rfc6350#section-6.5.1>
Internet Engineering Task Force (IETF) S. Perreault Request for Comments: 6350 Viagenie vCard Format Specification ... 6.5.1. TZ Purpose: To specify information related to the time zone of the object the vCard represents. ... Special notes: It is expected that names from the public-domain Olson database [TZ-DB] will be used, but this is not a restriction. See also [IANA-TZ]. A deprecated interface Examples: TZ:Raleigh/North America ... And an incorrect example. How does one correct an RFC? Who should do it? Wikipedia does a little better: <ihttps://en.wikipedia.org/wiki/VCard> TZ Optional The time zone of the vCard object. `2.1, 3.0: TZ:-0500 4.0: TZ:America/New_York -- gil
On Apr 21, 2023, at 4:30 PM, Paul Gilmartin via tz <tz@iana.org> wrote:
On 4/21/23 16:02:58, Guy Harris wrote:
If they have tools that support a proper UI for selecting tzdb regions, tell them your location and, if the UI doesn't recognize Suffolk, Montana or wherever you are, give them the location of a nearby city large enough to be notable. ... Then I thought my Contact card is a reasonable place to keep this. So: <https://datatracker.ietf.org/doc/html/rfc6350#section-6.5.1>
Internet Engineering Task Force (IETF) S. Perreault Request for Comments: 6350 Viagenie vCard Format Specification ... 6.5.1. TZ Purpose: To specify information related to the time zone of the object the vCard represents. ... Special notes: It is expected that names from the public-domain Olson database [TZ-DB] will be used, but this is not a restriction. See also [IANA-TZ].
A deprecated interface
What's deprecated here? (Presumably not tzids; vCard format appears to be one of those text-based-but-not-optimized-for-human-consumption formats that's primarily intended to be used in machine-to-machine communication, not human-to-machine or machine-to-human communication, so it's OK for it to use a tzid, also primarily intended to be consumed and produced by machines rather than directly used or generated by humans.)
Examples: TZ:Raleigh/North America ... And an incorrect example.
"It is expected that names from the public-domain Olson database [TZ-DB] will be used, *but this is not a restriction*.", so Raleigh/North America is a valid TZ value according to RFC 6350. Note that the TZ parameter can change even if, for example, the GEO parameter doesn't change, if you're in Wherever and Wherever decides to separate into West Whatever and East Whatever, with one of the two resulting Whatevers decides to have a new offset-from-UTC or a different set of DST rules, so that a bit of the tzdb region containing Whatever becomes a new tzdb region. So I'm not sure it's a good idea to put it into a vCard. With an appropriate mapping function, GEO would work better.
How does one correct an RFC?
Either file an erratum: https://www.rfc-editor.org/how-to-report/ or get involved with the group that developed it and push them to make an update (starting as an I-D) - that might be CalConnect, in this case: https://www.calconnect.org
On 4/21/23 18:02, Guy Harris via tz wrote:
or, if they have tools that support a crappy UI that exposes tzids, give them America/Denver, ask them what software they're using, and complain to the vendor of the software that they should do a better job. (There are various projects that can help, such as OpenStreetMap and the "shape files of tzdb regions" project, but it'd be nice if there were easier ways for tzdb users to find and use them.)
It's my recollection that the conference software the IETF uses exposes just such names. Please tellme I'm wrong.
On 2023-04-21 07:32, Benjamin Drung via tz wrote:
If people are aware of timezones, they often know UTC and their offsets (e.g. Europe/Berlin is UTC+2 summer). But they are probably not aware that the Etc/GMT offsets are inverted (e.g. you have to select Etc/GMT-2 for UTC+2). I was not aware of that and other people as well as the bugs in Ubuntu and Debian indicate (see https://launchpad.net/bugs/1325949 and https://bugs.debian.org/540305).
What do you think about the idea of introducing Etc/UTC+x timezones that have the "correct" offset so that people can select fixed offsets more easily? So Etc/GMT-2 would be renamed to Etc/UTC+2 and Etc/GMT-2 would become a symlink to it (same for all other Etc/GMT+x and Etc/GMT-x timezones).
ISO 4031:1978 first defined the representation of local time differentials, commonly referred to as time zones, with -W/+E. It appears POSIX +W/-E derives from SVID issue 1, published 1985 based on SVR2, possibly in (commercial) AT&T Unix 5 or earlier, supporting GMT and US time zones all positive. Anyone have access to earlier references to Unix time zones or TZ in sources? -- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
<<On Fri, 21 Apr 2023 12:10:39 -0600, Brian Inglis via tz <tz@iana.org> said:
ISO 4031:1978 first defined the representation of local time differentials, commonly referred to as time zones, with -W/+E.
It appears POSIX +W/-E derives from SVID issue 1, published 1985 based on SVR2, possibly in (commercial) AT&T Unix 5 or earlier, supporting GMT and US time zones all positive.
Anyone have access to earlier references to Unix time zones or TZ in sources?
Historically DST transition rules were compiled in to the C library. In Seventh Edition Unix, the ftime(2) system call filled in a `struct timeb` as follows: struct timeb { time_t time; unsigned short millitm; short timezone; short dstflag; }; <https://github.com/dspinellis/unix-history-repo/blob/Research-V7-Snapshot-De...> In later systems, there were actual comments: struct timeb { time_t time; /* seconds since the Epoch */ unsigned short millitm; /* + milliseconds since the Epoch */ short timezone; /* minutes west of CUT */ short dstflag; /* DST == non-zero */ }; [on my FreeBSD 12.4 system, because source compatibility] So it's definitely been "west is positive" since V7. Sixth Edition does not appear to contain the ftime(2) system call, although its source code structure is a lot less polished (there were still `ken` and `dmr` directories) so I can't be entirely sure I've looked in all the right places. -GAWollman
Date: Fri, 21 Apr 2023 14:42:39 -0400 From: Garrett Wollman via tz <tz@iana.org> Message-ID: <25666.55583.30059.744338@khavrinen.csail.mit.edu> | Sixth Edition | does not appear to contain the ftime(2) system call, although its | source code structure is a lot less polished (there were still `ken` | and `dmr` directories) so I can't be entirely sure I've looked in all | the right places. There was no ftime() everything was compiled into libc which in 6th edition contained the line: int timezone 5*60*60; which we'd write in modern C as int timezone = 5 * 60 * 60; That was for US Eastern time, and shows a positive timezone being used to mean west of Greenwich. I think it was that way in 5th edition as well - before then is before my time. kre
Brian Inglis asked, "Anyone have access to earlier references to Unix time zones or TZ in sources?" I found one; see second paragraph below. Let me start by saying that I'm an old-timer, and was interested in timekeeping and time zones long before the internet. During my time in the US Army (c. 1970), I recall we definitely used positive numbers for the number of hours west of Greenwich. (More often, though, we used letters, as 'R' for New York time.) I found a map in a US Navy World Time Zone Chart published 1940 which shows positive numbers west of Greenwich and negative numbers east. See https://www.ebay.com/itm/254655643832 . I'm sure there are hundreds of naval charts from and before that with the same convention. When the internet was young and I first saw the use of negative numbers for western offsets, I was sure it was a mistake. I still think so. Dave C. Date sent: Fri, 21 Apr 2023 12:10:39 -0600 To: tz@iana.org Organization: Inglis Subject: Re: [tz] Introduce Etc/UTC+x timezones? From: Brian Inglis via tz <tz@iana.org> Send reply to: Brian.Inglis@Shaw.ca
On 2023-04-21 07:32, Benjamin Drung via tz wrote:
If people are aware of timezones, they often know UTC and their offsets (e.g. Europe/Berlin is UTC+2 summer). But they are probably not aware that the Etc/GMT offsets are inverted (e.g. you have to select Etc/GMT-2 for UTC+2). I was not aware of that and other people as well as the bugs in Ubuntu and Debian indicate (see https://launchpad.net/bugs/1325949 and https://bugs.debian.org/540305).
What do you think about the idea of introducing Etc/UTC+x timezones that have the "correct" offset so that people can select fixed offsets more easily? So Etc/GMT-2 would be renamed to Etc/UTC+2 and Etc/GMT-2 would become a symlink to it (same for all other Etc/GMT+x and Etc/GMT-x timezones).
ISO 4031:1978 first defined the representation of local time differentials, commonly referred to as time zones, with -W/+E.
It appears POSIX +W/-E derives from SVID issue 1, published 1985 based on SVR2, possibly in (commercial) AT&T Unix 5 or earlier, supporting GMT and US time zones all positive.
Anyone have access to earlier references to Unix time zones or TZ in sources?
-- Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut -- Antoine de Saint-Exupéry
-- This email has been checked for viruses by AVG antivirus software. www.avg.com
Dave Cantor wrote:
When the internet was young and I first saw the use of negative numbers for western offsets, I was sure it was a mistake. I still think so.
Whether one is accustomed over time to seeing offsets west of UTC as positive or negative numbers, or whether the US Army or another organization uses one convention or the other, or whether C or another programming language uses one or the other, or whether one personally prefers the arithmetic relationship (UTC time *minus* five hours does equal standard time in New York), isn’t the question. The question is whether a new set of 26 identifiers should be created in the tz database which look like aliases for the existing “Etc/GMT±n” identifiers, but which in fact have the opposite meaning. I have to agree with Paul Eggert that this would add nothing but confusion. -- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org
On Fri, 21 Apr 2023 at 16:23, Doug Ewell via tz <tz@iana.org> wrote:
The question is whether a new set of 26 identifiers should be created in the tz database which look like aliases for the existing “Etc/GMT±n” identifiers, but which in fact have the opposite meaning.
I have to agree with Paul Eggert that this would add nothing but confusion.
FWIW, I'd pondered making a similar proposal a few years back, and similarly concluded that it's not worth the added confusion for many of the reasons already stated. At least not unless/until the backward-compatibility concerns leading to the existing Etc/GMT* zones will have (someday) outstayed their welcome, and even then we'd want to wait a good while before adding anything similar. -- Tim Parenti
On Mon, 2023-04-24 at 19:59 -0400, Tim Parenti via tz wrote:
On Fri, 21 Apr 2023 at 16:23, Doug Ewell via tz <tz@iana.org> wrote:
The question is whether a new set of 26 identifiers should be created in the tz database which look like aliases for the existing “Etc/GMT±n” identifiers, but which in fact have the opposite meaning.
I have to agree with Paul Eggert that this would add nothing but confusion.
FWIW, I'd pondered making a similar proposal a few years back, and similarly concluded that it's not worth the added confusion for many of the reasons already stated.
At least not unless/until the backward-compatibility concerns leading to the existing Etc/GMT* zones will have (someday) outstayed their welcome, and even then we'd want to wait a good while before adding anything similar.
Thanks for all the feedback - especially the history lesson about GMT vs. UTC. As result I will just clarify the difference between GMT and UTC offsets in the Debian/Ubuntu package. -- Benjamin Drung Debian & Ubuntu Developer
On Tue, May 2, 2023 at 07:30, Benjamin Drung via tz <tz@iana.org> wrote:
On Mon, 2023-04-24 at 19:59 -0400, Tim Parenti via tz wrote:
On Fri, 21 Apr 2023 at 16:23, Doug Ewell via tz <tz@iana.org> wrote:
The question is whether a new set of 26 identifiers should be created in the tz database which look like aliases for the existing “Etc/GMT±n” identifiers, but which in fact have the opposite meaning.
I have to agree with Paul Eggert that this would add nothing but confusion.
FWIW, I'd pondered making a similar proposal a few years back, and similarly concluded that it's not worth the added confusion for many of the reasons already stated.
At least not unless/until the backward-compatibility concerns leading to the existing Etc/GMT* zones will have (someday) outstayed their welcome, and even then we'd want to wait a good while before adding anything similar.
Thanks for all the feedback - especially the history lesson about GMT vs. UTC. As result I will just clarify the difference between GMT and UTC offsets in the Debian/Ubuntu package.
-- Benjamin Drung Debian & Ubuntu Developer
On Tue, May 2, 2023 at 07:31, Bavin Notn <notnbavin@gmail.com> wrote:
On Tue, May 2, 2023 at 07:30, Benjamin Drung via tz <tz@iana.org> wrote:
On Mon, 2023-04-24 at 19:59 -0400, Tim Parenti via tz wrote:
On Fri, 21 Apr 2023 at 16:23, Doug Ewell via tz <tz@iana.org> wrote:
The question is whether a new set of 26 identifiers should be created in the tz database which look like aliases for the existing “Etc/GMT±n” identifiers, but which in fact have the opposite meaning.
I have to agree with Paul Eggert that this would add nothing but confusion.
FWIW, I'd pondered making a similar proposal a few years back, and similarly concluded that it's not worth the added confusion for many of the reasons already stated.
At least not unless/until the backward-compatibility concerns leading to the existing Etc/GMT* zones will have (someday) outstayed their welcome, and even then we'd want to wait a good while before adding anything similar.
Thanks for all the feedback - especially the history lesson about GMT vs. UTC. As result I will just clarify the difference between GMT and UTC offsets in the Debian/Ubuntu package.
-- Benjamin Drung Debian & Ubuntu Developer
Benjamin Drung wrote:
Thanks for all the feedback - especially the history lesson about GMT vs. UTC. As result I will just clarify the difference between GMT and UTC offsets in the Debian/Ubuntu package.
Crucially, the difference we have been talking about is not between “GMT offsets” and “UTC offsets” per se, or between GMT and UTC themselves. It is between two notational conventions, one which assigns positive values to time zones west of the prime meridian and another which assigns negative values to them. There is history behind each of these competing decisions, but this is not a matter of “GMT vs. UTC,” and users who understand the actual relationship between GMT and UTC will only be confused by such a statement. -- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org
On Tue, 2023-05-02 at 14:49 +0000, Doug Ewell wrote:
Benjamin Drung wrote:
Thanks for all the feedback - especially the history lesson about GMT vs. UTC. As result I will just clarify the difference between GMT and UTC offsets in the Debian/Ubuntu package.
Crucially, the difference we have been talking about is not between “GMT offsets” and “UTC offsets” per se, or between GMT and UTC themselves. It is between two notational conventions, one which assigns positive values to time zones west of the prime meridian and another which assigns negative values to them.
There is history behind each of these competing decisions, but this is not a matter of “GMT vs. UTC,” and users who understand the actual relationship between GMT and UTC will only be confused by such a statement.
Help on wording will be highly appreciated. Currently debconf will ask "Please select the city or region corresponding to your time zone. Time zone: GMT, GMT+0, GMT+1, ..., GMT-9, Greenwich, UCT, UTC, Universal, Zulu". Draft: "Please select the offset corresponding to your time zone. Contrary to UTC, positive values to GMT refer to zones west to Greenwich and negative values to east to Greenwich (e.g. UTC-6 = GMT+6). Time zone: GMT, GMT+0, GMT+1, ..., GMT-9, Greenwich, UCT, UTC, Universal, Zulu". -- Benjamin Drung Debian & Ubuntu Developer
On Tue 2023-05-02T17:19:06+0200 Benjamin Drung via tz hath writ:
Draft: "Please select the offset corresponding to your time zone. Contrary to UTC, positive values to GMT refer to zones west to Greenwich and negative values to east to Greenwich (e.g. UTC-6 = GMT+6). Time zone: GMT, GMT+0, GMT+1, ..., GMT-9, Greenwich, UCT, UTC, Universal, Zulu".
Because of its defining expression UT has been departing from GMT for 120 years, but the difference remains inconsequentially small. The wording above will get more complicated by mid 21st century as UTC deviates notably from GMT. -- 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 Tue, 2023-05-02 at 08:52 -0700, Steve Allen via tz wrote:
On Tue 2023-05-02T17:19:06+0200 Benjamin Drung via tz hath writ:
Draft: "Please select the offset corresponding to your time zone. Contrary to UTC, positive values to GMT refer to zones west to Greenwich and negative values to east to Greenwich (e.g. UTC-6 = GMT+6). Time zone: GMT, GMT+0, GMT+1, ..., GMT-9, Greenwich, UCT, UTC, Universal, Zulu".
Because of its defining expression UT has been departing from GMT for 120 years, but the difference remains inconsequentially small.
The wording above will get more complicated by mid 21st century as UTC deviates notably from GMT.
For the tz project UTC = GMT, isn't it? Can you suggest a better wording? -- Benjamin Drung Debian & Ubuntu Developer
On Tue, 2 May 2023 at 11:19, Benjamin Drung <benjamin.drung@canonical.com> wrote:
Help on wording will be highly appreciated. Currently debconf will ask "Please select the city or region corresponding to your time zone. Time zone: GMT, GMT+0, GMT+1, ..., GMT-9, Greenwich, UCT, UTC, Universal, Zulu".
Draft: "Please select the offset corresponding to your time zone. Contrary to UTC, positive values to GMT refer to zones west to Greenwich and negative values to east to Greenwich (e.g. UTC-6 = GMT+6). Time zone: GMT, GMT+0, GMT+1, ..., GMT-9, Greenwich, UCT, UTC, Universal, Zulu".
It would be more accurate to say something more along the lines of: "Contrary to modern conventions, POSIX-compatible zones use positive values to refer to zones west of Greenwich and negative values for those east of Greenwich (e.g., 'Etc/GMT+6' refers to 6 hours west of Greenwich, commonly called 'UTC-6')." On Tue, 2 May 2023 at 12:43, Benjamin Drung via tz <tz@iana.org> wrote:
For the tz project UTC = GMT, isn't it?
To most practical effect, yes. That's why, if possible, I would recommend avoiding exposing POSIX-signed terms like "GMT±n" without the leading "Etc/" used in the full zone name, as that could contribute further to exactly the type of confusion you seek to avoid. -- Tim Parenti
On Tue, 2023-05-02 at 13:13 -0400, Tim Parenti wrote:
On Tue, 2 May 2023 at 11:19, Benjamin Drung <benjamin.drung@canonical.com> wrote:
Help on wording will be highly appreciated. Currently debconf will ask "Please select the city or region corresponding to your time zone. Time zone: GMT, GMT+0, GMT+1, ..., GMT-9, Greenwich, UCT, UTC, Universal, Zulu".
Draft: "Please select the offset corresponding to your time zone. Contrary to UTC, positive values to GMT refer to zones west to Greenwich and negative values to east to Greenwich (e.g. UTC-6 = GMT+6). Time zone: GMT, GMT+0, GMT+1, ..., GMT-9, Greenwich, UCT, UTC, Universal, Zulu".
It would be more accurate to say something more along the lines of:
"Contrary to modern conventions, POSIX-compatible zones use positive values to refer to zones west of Greenwich and negative values for those east of Greenwich (e.g., 'Etc/GMT+6' refers to 6 hours west of Greenwich, commonly called 'UTC-6')."
Thanks. I will use this explanation in the debconf prompt. Thanks for all feedback in this thread. Some responses demonstrated that I failed to describe the context. On Debian/Ubuntu systems users normally select their timezones with a location picker. The tzdata package comes with debconf questions to set the timezone. You can see them by running "dpkg-reconfigure tzdata". It will first ask for the area (like Europe, America, Etc). Then it will ask for the country. -- Benjamin Drung Debian & Ubuntu Developer
On Tue 2023-05-02T18:43:37+0200 Benjamin Drung hath writ:
The wording above will get more complicated by mid 21st century as UTC deviates notably from GMT.
For the tz project UTC = GMT, isn't it? Can you suggest a better wording?
Alas no. The folks pushing to abandon the leap second have admitted that some kind of adjustment of "new UTC" will eventually be needed lest it deviate too far from GMT. That remains unexplored. It will want worldwide consensus of governments and data models on a meaning of time and calendar days which is satisfactory for political and technical purposes. If a government objects to a deviation of 15 seconds that agreement could be needed by 2050, but a larger tolerance should be acceptable and that should push the need to the end of this century. The current wording is sloppy because UT (and UT1) have always been deviating from GMT, just not by enough for people to notice. The better wording cannot happen until there is a vocabulary for what we want time to mean and to tell us. -- 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
Benjamin Drung wrote:
Draft: "Please select the offset corresponding to your time zone. Contrary to UTC, positive values to GMT refer to zones west to Greenwich and negative values to east to Greenwich (e.g. UTC-6 = GMT+6). Time zone: GMT, GMT+0, GMT+1, ..., GMT-9, Greenwich, UCT, UTC, Universal, Zulu".
This is exactly how you do NOT want to express it. This is NOT about UTC, the time standard, versus GMT, the time standard. For purposes of identifying time zones, UTC and GMT are the same thing. They are defined differently and can differ by up to 0.9 seconds, but that is not relevant to the present discussion. The convention of denoting offsets west of 0° with positive numbers and offsets east of 0° with negative offsets is a POSIX thing. It has nothing to do with any differences between UTC and GMT. Telling users it does will only confuse and mislead them. Tim Parenti’s suggested wording captures the actual issue quite clearly, and I recommend using it. His suggestion to steer users toward geographically based zones and away from the “Etc/GMT±x” identifiers is also recommended. -- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org
I wrote:
Tim Parenti’s [...] suggestion to steer users toward geographically based zones and away from the “Etc/GMT±x” identifiers is also recommended.
My apologies; I misread what Tim wrote. He was suggesting to keep the “Etc/” prefix to avoid confusion as to what notation like “GMT+1” actually means. Others have indeed suggested using geographically named time zone identifiers, and I agree with them. -- Doug Ewell, CC, ALB | Lakewood, CO, US | ewellic.org
On Tue, 2 May 2023 at 13:35, Doug Ewell <doug@ewellic.org> wrote:
My apologies; I misread what Tim wrote. He was suggesting to keep the “Etc/” prefix to avoid confusion as to what notation like “GMT+1” actually means.
Others have indeed suggested using geographically named time zone identifiers, and I agree with them.
To be clear, in descending order of preference: 1. Use geographical lookup to avoid these issues altogether 2. Expose full geographical tzids with local rules — not without problems, but fairly common 3. Expose something like "UTC-06" to select "Etc/GMT+6", abstracting away the POSIX sign-flipping from users' perspective 4. Expose full non-geographical names like "Etc/GMT+6" but be ABUNDANTLY clear in explaining what they mean in context 5. Leave users to guess or infer what the sign means The gaps between most of these rungs in terms of overall user experience are pretty steep. My suggestion was more about moving up this ladder in the context of those who are already eschewing the top two options, for whatever reason. -- Tim Parenti
On May 2, 2023, at 10:49 AM, Tim Parenti via tz <tz@iana.org> wrote:
To be clear, in descending order of preference:
1. Use geographical lookup to avoid these issues altogether
Where "geographical lookup" can include: using some form of known location of the machine (using various mechanisms such as Location Services in macOS and whatever services are made possible by libraries and frameworks in other environments), combined with maps of tzdb region boundaries, so the user doesn't have to pick a tzdb region in the first place (and, if you're ambitious, add a mechanism to allow the tzdb region to change out from under a process, and change it when the machine moves from region to region, as macOS/iOS/iPadOS/watchOS/tvOS if you're carrying your TV and Apple TV box with you on a moving vehicle :-) do); allowing the user to select a location on a map; allowing the user to, for example, select a country and, when they've selected a country, select a nearest city from a list of cities in that country; etc.. (Borrow a Mac and see how it's done there.) All of those have the advantage of completely hiding tzids from the user.
Benjamin Drung via tz <tz@iana.org> writes:
Help on wording will be highly appreciated. Currently debconf will ask "Please select the city or region corresponding to your time zone. Time zone: GMT, GMT+0, GMT+1, ..., GMT-9, Greenwich, UCT, UTC, Universal, Zulu".
Draft: "Please select the offset corresponding to your time zone. Contrary to UTC, positive values to GMT refer to zones west to Greenwich and negative values to east to Greenwich (e.g. UTC-6 = GMT+6). Time zone: GMT, GMT+0, GMT+1, ..., GMT-9, Greenwich, UCT, UTC, Universal, Zulu".
Personally, I would hide all of the GMT language completely in the prompt and instead offer as choices UTC-1, UTC-2, UTC-3, etc., and then convert them under the hood to the GMT+1, etc., zones if one of those were chosen. Due to RFC 822 and other subsequent standardization, I think the majority of people (among those who would consider configuring an offset time zone instead of a geographic one) are going to be familiar with the sign convention that matches that used in RFC 822 and are not going to expect the opposite sign convention. Rather than trying to explain it in text that people may not read, I would just hide it. Similarly, I wouldn't expose labels like Greenwich, UCT, Universal, Zulu, etc. I don't think that stuff is useful in a UI for zone picking. -- Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>
Date: Fri, 21 Apr 2023 15:47:29 -0400 From: Dave Cantor via tz <tz@iana.org> Message-ID: <6442E851.5805.24513469@Dave.DaveCantor.us> | When the internet was young and I first saw the use of negative | numbers for western offsets, I was sure it was a mistake. I | still think so. Neither is right or wrong, you can consider the offset to be the number you add to UTC times to get the local time, or the number you add to local time to get a UTC time. One of those is obviously going to be positive, and the other negative. Which is used in the notation which describes a zone is (or was, it is settled now) arbitrary (and was most likely done differently by different people). Then consider the number of countries who send representatives to ISO which are located west of Greenwich, compared to the number which are located east of Greenwich, and guess which group has the voting power to have their offsets (as written in the notation) the positive ones? kre
On 2023-04-21 18:10, Brian Inglis via tz wrote:
ISO 4031:1978 first defined the representation of local time differentials, commonly referred to as time zones, with -W/+E.
The choice of the term "local time differential" was unfortunate because commonly, a differential is not a difference. The terminology was changed • in [ISO 8601:1988] to "time difference" • in [ISO 8601-1:2019] to "time shift" but the definition as time shift = local time - UTC remained the same. Michael Deckers.
participants (16)
-
Bavin Notn -
Benjamin Drung -
Brian Inglis -
Dave Cantor -
Derick Rethans -
Doug Ewell -
Garrett Wollman -
Guy Harris -
Michael Douglass -
Michael H Deckers -
Paul Eggert -
Paul Gilmartin -
Robert Elz -
Russ Allbery -
Steve Allen -
Tim Parenti