
Dear Colleagues, As a citizen of Tomsk, I would like to raise some questions concerning the recent addition of the Asia/Tomsk timezone. As you know, this time zone's abbreviation is all numeric: Zone Asia/Tomsk 5:39:51 - LMT 1919 Dec 22 6:00 - +06 1930 Jun 21 7:00 Russia +07/+08 1991 Mar 31 2:00s 6:00 Russia +06/+07 1992 Jan 19 2:00s 7:00 Russia +07/+08 2002 May 1 3:00 6:00 Russia +06/+07 2011 Mar 27 2:00s 7:00 - +07 2014 Oct 26 2:00s 6:00 - +06 2016 May 29 2:00s 7:00 - +07 In my opinion, it is bad for two reasons: 1. zic warns that 'warning: time zone abbreviation differs from POSIX standard (+06)' 2. Such an abbreviation is not user friendly and even borders on offensive. A locality deserves a name! Could we do something about Asia/Tomsk and other zones with share the same fate: Europe/Astrakhan, Europe/Kirov, Europe/Ulyanovsk, Asia/Barnaul? Thank you for your attention. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov@sibptus.tomsk.ru

On Wed, May 25, 2016, at 10:35, Victor Sudakov wrote:
1. zic warns that 'warning: time zone abbreviation differs from POSIX standard (+06)'
2. Such an abbreviation is not user friendly and even borders on offensive. A locality deserves a name!
What is this time zone called in Russia? As I understand it, the issue is that people don't like the idea of the tz project just making these things up anymore.

Random832 wrote:
1. zic warns that 'warning: time zone abbreviation differs from POSIX standard (+06)'
2. Such an abbreviation is not user friendly and even borders on offensive. A locality deserves a name!
What is this time zone called in Russia?
So far we have used the Asia/Omsk (OMST) or Asia/Novosibirsk (NOVT) time zones, so I don't think this new time zone has a name yet. On Cisco routers, I have often named it TSK/TSD, but that's probably just me. Should we perhaps name Asia/Tomsk "KRAT" because it will be identical to Krasnoyarsk since 2016 May 29, and was identical to "NOVT" before that?
As I understand it, the issue is that people don't like the idea of the tz project just making these things up anymore.
As a member of the public, I don't like the idea of the tz project calling my time zone <+07> :-) Do you suggest I should interview Tomsk sysadmins about the possible name? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov@sibptus.tomsk.ru

On May 25, 2016, at 10:19 AM, Victor Sudakov <vas@mpeks.tomsk.su> wrote:
As a member of the public, I don't like the idea of the tz project calling my time zone <+07> :-)
As a member of the tzdb project (albeit one whose main effort was ages ago), I don't like the idea of expecting people not necessarily from the locale of a tzdb zone to pick abbreviations for times in the zone and then deal with complaints from people from that locale. :-)
Do you suggest I should interview Tomsk sysadmins about the possible name?
Asking people from the Asia/Tomsk tzdb zone is certainly better than expecting people *not* from that zone to pick an abbreviation. It looks as if there's no daylight savings time, so only one abbreviation is necessary. Just make sure you pick an abbreviation to which nobody within that zone will object to, so we don't have to forward their complaints to the people who picked the abbreviation. Note that the abbreviation must not use characters other than "alphanumeric characters from the portable character set in the current locale, the <plus-sign> ( '+' ) character, or the minus-sign ( '-' ) character", as per the description of TZ in http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html and the description of the tzname array in http://pubs.opengroup.org/onlinepubs/9699919799/functions/tzset.html (Paul, is the idea that you could have an abbreviation such as "EST+3", not just something like "+03"? And what does "the portable character set in the current locale" mean? Isn't the portable character set: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap06.html supposed to be the characters present in *all* locales?)

On May 26, 2016, at 2:08 AM, Guy Harris <guy@alum.mit.edu> wrote:
It looks as if there's no daylight savings time, so only one abbreviation is necessary.
Oops, no, it had DST from 1991 to 2014, and flipped between time zones, so multiple abbreviations are necessary. Do you have enough of a consensus that {OMST, OMS{S,D}T, KRAT} are something we can go with as "not inventions of the tzdb maintainers"?

Guy Harris wrote:
It looks as if there's no daylight savings time, so only one abbreviation is necessary.
Oops, no, it had DST from 1991 to 2014,
to 2011. DST was abolished by President Medvedev in 2011.
and flipped between time zones, so multiple abbreviations are necessary.
True. I am not sure however whether we were really in the Omsk or in the Krasnoyarsk timezone at a given time e.g. in 1995.
Do you have enough of a consensus that {OMST, OMS{S,D}T, KRAT} are something we can go with as "not inventions of the tzdb maintainers"?
I think the OMST and KRAT abbreviations have a long history dating back 10 years or more. Is there a VCS repository for the timezone data somewhere so that we could look it up? This should give them some credit. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov@sibptus.tomsk.ru

On Thu, 26 May 2016, Victor Sudakov wrote:
Do you have enough of a consensus that {OMST, OMS{S,D}T, KRAT} are something we can go with as "not inventions of the tzdb maintainers"?
I think the OMST and KRAT abbreviations have a long history dating back 10 years or more.
Is there a VCS repository for the timezone data somewhere so that we could look it up? This should give them some credit.
I don't think we want to rely on archives of our own timezone data, since we've already acknowledged that the relevant zone abbreviations there were "invented" by ourselves. Rather, we would like some external, independant references for what is the actual usage in the affected area. +------------------+--------------------------+------------------------+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired) | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com | | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | +------------------+--------------------------+------------------------+

On 05/26/2016 03:30 AM, Paul Goyette wrote:
Rather, we would like some external, independant references for what is the actual usage in the affected area.
And the tz database is English-language: it is not designed to record abbreviations used in Russian. We need reliable sources for English-language abbreviations for the time zones in question. Unfortunately the subject comes up rarely enough in English that abbreviations are unlikely in practice.

On 25/05/2016 15:35, Victor Sudakov wrote:
Dear Colleagues,
As a citizen of Tomsk, I would like to raise some questions concerning the recent addition of the Asia/Tomsk timezone. As you know, this time zone's abbreviation is all numeric:
Zone Asia/Tomsk 5:39:51 - LMT 1919 Dec 22 6:00 - +06 1930 Jun 21 7:00 Russia +07/+08 1991 Mar 31 2:00s 6:00 Russia +06/+07 1992 Jan 19 2:00s 7:00 Russia +07/+08 2002 May 1 3:00 6:00 Russia +06/+07 2011 Mar 27 2:00s 7:00 - +07 2014 Oct 26 2:00s 6:00 - +06 2016 May 29 2:00s 7:00 - +07
In my opinion, it is bad for two reasons:
1. zic warns that 'warning: time zone abbreviation differs from POSIX standard (+06)'
Recent enough versions of zic don't issue that warning. If you wanted to put such an abbreviation in a POSIX-style TZ environment variable value, it would need to be placed in angle brackets like this: TZ='<+07>-7' (which, admittedly, looks a little odd, but that's the fault of UNIX tradition).
2. Such an abbreviation is not user friendly and even borders on offensive. A locality deserves a name!
On the positive side, at least it lets the user know how far the time zone is from UTC! -- -=( Ian Abbott @ MEV Ltd. E-mail: <abbotti@mev.co.uk> )=- -=( Web: http://www.mev.co.uk/ )=-

Ian Abbott wrote:
2. Such an abbreviation is not user friendly and even borders on offensive. A locality deserves a name!
On the positive side, at least it lets the user know how far the time zone is from UTC!
That's what 'date +%z' is for. Seriously, if there is a trend to abandon symbolic names, there is probably no use inventing a name for the newborn Asia/Tomsk zone. As can be seen from the map http://world-time-zones.ru/russia.htm the history of Tomsk time is the process of oscillations between the Omsk and Krasnoyarsk zones, so I suggest: Zone Asia/Tomsk 5:39:51 - LMT 1919 Dec 22 6:00 - OMST 1930 Jun 21 7:00 Russia OMS%sT 1991 Mar 31 2:00s 6:00 Russia OMS%sT 1992 Jan 19 2:00s 7:00 Russia OMS%sT 2002 May 1 3:00 6:00 Russia OMS%sT 2011 Mar 27 2:00s 7:00 - OMST 2014 Oct 26 2:00s 6:00 - OMST 2016 May 29 2:00s 7:00 - KRAT -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov@sibptus.tomsk.ru

Victor Sudakov wrote:
Seriously, if there is a trend to abandon symbolic names, there is probably no use inventing a name for the newborn Asia/Tomsk zone. As can be seen from the map http://world-time-zones.ru/russia.htm the history of Tomsk time is the process of oscillations between the Omsk and Krasnoyarsk zones, so I suggest:
Zone Asia/Tomsk 5:39:51 - LMT 1919 Dec 22 6:00 - OMST 1930 Jun 21 7:00 Russia OMS%sT 1991 Mar 31 2:00s 6:00 Russia OMS%sT 1992 Jan 19 2:00s 7:00 Russia OMS%sT 2002 May 1 3:00 6:00 Russia OMS%sT 2011 Mar 27 2:00s 7:00 - OMST 2014 Oct 26 2:00s 6:00 - OMST 2016 May 29 2:00s 7:00 - KRAT
Oops, we were in the Krasnoyarsk timezone in the USSR: http://topmap.su/sng/ussr-clock.html so it's rather like this: Zone Asia/Tomsk 5:39:51 - LMT 1919 Dec 22 6:00 - KRAT 1930 Jun 21 7:00 Russia KRA%sT 1991 Mar 31 2:00s 6:00 Russia OMS%sT 1992 Jan 19 2:00s 7:00 Russia OMS%sT 2002 May 1 3:00 6:00 Russia OMS%sT 2011 Mar 27 2:00s 7:00 - OMST 2014 Oct 26 2:00s 6:00 - OMST 2016 May 29 2:00s 7:00 - KRAT Back in the USSR! -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov@sibptus.tomsk.ru

Victor Sudakov wrote:
so it's rather like this:
Zone Asia/Tomsk 5:39:51 - LMT 1919 Dec 22 6:00 - KRAT 1930 Jun 21 7:00 Russia KRA%sT 1991 Mar 31 2:00s 6:00 Russia OMS%sT 1992 Jan 19 2:00s 7:00 Russia OMS%sT 2002 May 1 3:00 6:00 Russia OMS%sT 2011 Mar 27 2:00s 7:00 - OMST 2014 Oct 26 2:00s 6:00 - OMST 2016 May 29 2:00s 7:00 - KRAT
The Asia/Novokuznetsk zone is organized in the same way: it does not have a separate abbreviation but rather reflects the oscillations of Novokuznetsk between the NOVT and KRAT timezones. Can we model Asia/Tomsk after that (see above)? -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov@sibptus.tomsk.ru

Paul Eggert wrote:
The Asia/Novokuznetsk zone is organized in the same way
Asia/Novokuznetsk also has English-language abbreviations that we invented,
But these abbreviations are already sanctified by a long tradition. They must have been around for over 20 years (I began using FreeBSD around 1995 and I remember those abbreviations being there).
and the plan is to migrate it to numeric abbreviations as well;
When are you planning to migrate the abbreviations like EST or HST? If a timezone has a non-integer offset like 10:30, what numeric abbreviation are you planning to use?
tzdata should record timekeeping practice, not invent it.
Nobody here in Tomsk calls our timezone "+07" in practice, I assure you. That's just another invention, albeit a more unsightly one. We call it "6-я часовая зона" (officially), or "Красноярское время", but you don't allow non-ascii names. Or maybe Windows users call it "UTC +07:00" or Android users "Красноярск", but never "+07". -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov@sibptus.tomsk.ru

Victor Sudakov wrote:
But these abbreviations are already sanctified by a long tradition.
Not really. And I have some experience in this, as I am the one who *invented* that "long tradition", and I've seen it not catch on.
When are you planning to migrate the abbreviations like EST or HST?
EST and HST have been commonly used by reliable English-language sources for decades. We did not invent these abbreviations, and don't plan to remove them.
If a timezone has a non-integer offset like 10:30, what numeric abbreviation are you planning to use?
The one that zic generates with %z. +1030 in that case.
Nobody here in Tomsk calls our timezone "+07" in practice, I assure you. That's just another invention
Yes, I wouldn't expect people in Tomsk to use English-language abbreviations. They would use Russian-language abbreviations, if anything. Numeric abbreviations reasonably common, and are standardized by ISO 8601.
We call it "6-я часовая зона" (officially), or "Красноярское время", but you don't allow non-ascii names.
Yes, the idea is to use an English-language abbreviation if there is one in common use, and to fall back on a numeric abbreviation otherwise.

Paul Eggert wrote:
Victor Sudakov wrote:
But these abbreviations are already sanctified by a long tradition.
Not really. And I have some experience in this, as I am the one who *invented* that "long tradition", and I've seen it not catch on.
Sources like the ones below are not good enough? https://en.wikipedia.org/wiki/Krasnoyarsk_Time https://ru.flightaware.com/live/airport/UNKL https://savvytime.com/converter/btt-to-krat In fact, I have obtained them just from googling for "KRAT NOVT", there are thousands.
When are you planning to migrate the abbreviations like EST or HST?
EST and HST have been commonly used by reliable English-language sources for decades. We did not invent these abbreviations, and don't plan to remove them.
I also suggest you please don't remove the abbreviations which are already there and used by thousands of systems and sites. This is Bolshevism. I am not saying anymore that Tomsk or some new addition to the database should trigger the creation of a brand-new abbreviation. But you could at least keep the symbolic abbreviations for major time zones (we have 11 of them in Russia). -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov@sibptus.tomsk.ru

On Thu 2016-06-02T07:41:00 -0700, Paul Eggert hath writ:
No, not at all. The Wikipedia page is derived from tzdata, and is not a reliable source is its own right. The other sources are not English-language.
It would be ironic if it turns out that tzdata abandons these abbreviations and then the popular demand lobbying moves to the Unicode Consortium who might then re-instate them. -- Steve Allen <sla@ucolick.org> WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m

On 06/02/2016 07:50 AM, Steve Allen wrote:
It would be ironic if it turns out that tzdata abandons these abbreviations and then the popular demand lobbying moves to the Unicode Consortium who might then re-instate them.
The Unicode Consortium is welcome to maintain them, just as they're welcome to maintain other information like the nominative vs the genitive case of Russian month names (a real bug with tzcode 'strftime' in Russian locales, by the way -- any volunteers to fix that? :-). The Consortium has the resources to deal with this sort of thing. We don't. Another reason for not using these abbreviations, which I haven't perhaps made clear, is to avoid arbitrating disputes over what the time zone abbreviations should be. A user could reasonably complain "Why are you making up an abbreviation that calls it Krasnoyarsk Time? This is Tomsk, not Krasnoyarsk!" The current kerfuffle is just the tip of the iceberg, and the problem will get worse as the number of tzdata names increases. These abbreviations are entirely invented and are not needed to solve time zone issues. All too often disagreements about them degenerate into political disputes that distract from tzdata's main goal, and we need to get out of the business of making them up or trying to defend them.

On Thu, Jun 2, 2016, at 11:37, Paul Eggert wrote:
These abbreviations are entirely invented and are not needed to solve time zone issues.
So remove the feature entirely. Otherwise aren't we implicitly conceding that supporting "time zone names" (tzname, tm_zone, and strftime's %Z) is in fact a "time zone issue" which the abbreviations *are* needed to solve?

02.06.2016 22:37, Paul Eggert wrote:
Another reason for not using these abbreviations, which I haven't perhaps made clear, is to avoid arbitrating disputes over what the time zone abbreviations should be. A user could reasonably complain "Why are you making up an abbreviation that calls it Krasnoyarsk Time? This is Tomsk, not Krasnoyarsk!" The current kerfuffle is just the tip of the iceberg, and the problem will get worse as the number of tzdata names increases.
There is the same cities (Novosibirsk / Krasnoyarsk) in timezones on Android and Windows OS (and there are a lot of users of these OS), so you can treat these as common-used names for timezones. I suppose what this argument, together with the previously listed arguments, is enough to set abbreviations in 'Asia/Tomsk' to NOVT/KRAT like already done in 'Asia/Novokuznetsk'. Also please note what 'Asia/Novokuznetsk' uses not only similar schema of 'to take abbreviations from nearby timezone' but the same timezones.
These abbreviations are entirely invented and are not needed to solve time zone issues. All too often disagreements about them degenerate into political disputes that distract from tzdata's main goal, and we need to get out of the business of making them up or trying to defend them.
So remove the feature entirely. But, you already answered what you do not have such plans:
EST and HST have been commonly used by reliable English-language sources for decades. We did not invent these abbreviations, and don't plan to remove them.
I do not see anything good in the current state when some timezones have abbreviations and some have not. All timezones should have the same approach. -- Regards, Pavel.

On 06/02/2016 01:16 PM, Pavel V. Rochnyack wrote:
I suppose what this argument, together with the previously listed arguments, is enough to set abbreviations in 'Asia/Tomsk' to NOVT/KRAT like already done in 'Asia/Novokuznetsk'.
This is the sort of thing we're trying to move away from. Abbreviations like NOVT are our inventions and are rarely used outside the tzdata context; we really can't defend them. Another problem with abbreviations like NOVT is that their meanings change with time. For example, NOVT stands for +06 now, but it stands for +07 before October 2014, for +06 again before March 2011, etc. The ambiguity of "NOVT" is atypical for English-language time zone abbreviations, and this unexpected aspect of our invented abbreviations can easily confuse non-experts. In contrast, abbreviations like +06 and +07 are unambiguous.
So remove the feature entirely.
That's not a practical option, as time zone abbreviations are a standard part of ISO C, of POSIX, and of many programming systems that use a tzcode-like interface, so we need to put *something* in there. Numeric abbreviations are reasonable placeholders for zones lacking well-supported English-language time zone abbreviations.

On Thu, Jun 2, 2016, at 16:54, Paul Eggert wrote:
This is the sort of thing we're trying to move away from. Abbreviations like NOVT are our inventions and are rarely used outside the tzdata context; we really can't defend them.
Defend them from whom?
Another problem with abbreviations like NOVT is that their meanings change with time. For example, NOVT stands for +06 now, but it stands for +07 before October 2014, for +06 again before March 2011, etc. The ambiguity of "NOVT" is atypical for English-language time zone abbreviations, and this unexpected aspect of our invented abbreviations can easily confuse non-experts.
So fix them. No-one's saying they should continue *exactly* as they have been, just that whatever solution is arrived at should not be a bare number.
In contrast, abbreviations like +06 and +07 are unambiguous.
They're unclear as to what their units are or what they are to be added to. A field that has traditionally been a reasonably self-explanatory abbreviation is unlikely to exclusively appear in contexts where it's unambiguous that it is an offset in hours to be treated as a difference from UTC to identify the time zone.
So remove the feature entirely.
That's not a practical option, as time zone abbreviations are a standard part of ISO C, of POSIX,
To be clear, these fields are consistently and exclusively referred to as *names* in the relevant standards, and the restrictions that POSIX places on their contents (for example, no spaces) only apply, in a strict reading, to the "STDnDST..."-style TZ environment variable, and not to time zone names set in an implementation-defined manner from the other form of TZ environment variable. Windows uses full names, with this particular zone being called "N. Central Asia Standard Time".
and of many programming systems that use a tzcode-like interface, so we need to put *something* in there.
Sure. Put the numeric zone identifier in there. Preferably to the minute, if there's room, since that's what people expect. And put it there for *everyone*, and remove support for storing or loading a non-numeric abbreviation in the datafiles.
Numeric abbreviations are reasonable placeholders for zones lacking well-supported English-language time zone abbreviations.
Says who? This entire discussion was started by people who don't think that's reasonable. And I certainly don't think "The US and Europe get abbreviations and Russia does not" is reasonable.

Random832 wrote:
Defend them from whom?
From discussions like these. :-) For Tomsk, for example, should the abbreviation be TOMT or KRAT or NOVT or what?
No-one's saying they should continue *exactly* as they have been
Actually there is some sentiment for leaving things alone, a sentiment I would ordinarily share. Unfortunately the invented alphabetic abbreviations are too often broken, and the introduction of Asia/Tomsk is rubbing our noses in the breakage.
these fields are consistently and exclusively referred to as *names* in the relevant standards
Not really. ISO C11 calls strftime %Z "the locale's time zone name or abbreviation". POSIX's formal description of the TZ environment variable uses the term "designation" to describe these fields. In ordinary English one would ordinarly use "abbreviation" to describe "PST" etc.; "name" would be used for phrases like "Pacific Standard Time". The ISO C and POSIX standards allow these fields to be used for either names (as in MS-Windows) or abbreviations (as in tzdata); in tzdata they are always abbreviations.
I certainly don't think "The US and Europe get abbreviations and Russia does not" is reasonable.
Quite right, the guideline should not pick on Russia, and that's not the intent. Russia's new zones (along with some non-Russian arctic and antarctic entries) merely happen to be the first places the revised guideline is being used. The idea is to take our time in converting, in order to shake out implementation bugs. (You can see the guideline in the "Theory" file; look for "Time zone abbreviations".) Victor Sudakov wrote:
Windows uses abbreviations like RTZ6 for Russian timezones. Is Microsoft a reliable independent English-language source in your opinion?
Not really, as Microsoft just invented their abbreviations too, and my impression is that abbreviations like RTZ6 are extremely rare in English-language text, even rarer than abbreviations like KRAT.

03.06.2016 12:49, Paul Eggert пишет:
Quite right, the guideline should not pick on Russia, and that's not the intent. Russia's new zones (along with some non-Russian arctic and antarctic entries) merely happen to be the first places the revised guideline is being used. The idea is to take our time in converting, in order to shake out implementation bugs. (You can see the guideline in the "Theory" file; look for "Time zone abbreviations".)
At the same moment, you write:
EST and HST have been commonly used by reliable English-language sources for decades. We did not invent these abbreviations, and don't plan to remove them.
All timezones should have the same approach. Also, in the "Theory" file where is:
If there is no common English abbreviation, abbreviate the English translation of the usual phrase used by native speakers.
At the moment, as for Tomsk citizens, phrazes like 'we are living by Novosibirsk [time]' before time shift and 'we are using Krasnoyark time' are common enough. Google shows enough results about this query: "Томск переходит в Красноярский часовой пояс" (translation: "Tomsk enters the Krasnoyarsk Time Zone") -- Regards, Pavel.

03.06.2016 в 13:16:33 +0700 Pavel V. Rochnyack написал:
Also, in the "Theory" file where is:
If there is no common English abbreviation, abbreviate the English translation of the usual phrase used by native speakers.
At the moment, as for Tomsk citizens, phrazes like 'we are living by Novosibirsk [time]' before time shift and 'we are using Krasnoyark time' are common enough.
Google shows enough results about this query: "Томск переходит в Красноярский часовой пояс" (translation: "Tomsk enters the Krasnoyarsk Time Zone")
And many articles say "Tomsk moves to summer time" about the same event. Soon Tomsk time, Krasnoyarsk time, Novosibirsk time would mean the same thing and all will be in use. Why and how should tzdata choose one of them?

03.06.2016 13:50, Stepan Golosunov пишет:
03.06.2016 в 13:16:33 +0700 Pavel V. Rochnyack написал:
Also, in the "Theory" file where is:
If there is no common English abbreviation, abbreviate the English translation of the usual phrase used by native speakers.
At the moment, as for Tomsk citizens, phrazes like 'we are living by Novosibirsk [time]' before time shift and 'we are using Krasnoyark time' are common enough.
Google shows enough results about this query: "Томск переходит в Красноярский часовой пояс" (translation: "Tomsk enters the Krasnoyarsk Time Zone")
And many articles say "Tomsk moves to summer time" about the same event. Soon Tomsk time, Krasnoyarsk time, Novosibirsk time would mean the same thing and all will be in use. Why and how should tzdata choose one of them?
Assigning 'NOVT/KRAT' abbreviations to 'Asia/Tomsk' does not introduce new problem, the 'Asia/Novokuznetsk' is already here. If Noviosibirsk and Krasnoyarsk will be in the same time zone: Will you change 'NOVT' in 'Asia/Novosibirsk' due to that change? Probably, not. Will you change 'KRAT' in 'Asia/Krasnoyarsk' due to that change? Not, of course. Will you change 'KRAT' in 'Asia/Novokuznetsk' due to that change? Probably, not. The same (no changes in 'KRAT' abbreviation) should happen with 'Asia/Tomsk' in that case. Again: All timezones should have the same approach. If you don't want abbreviations - remove them completely. If you don't want to remove abbreviations - set them. If you don't want to set 'NOVT/KRAT' - make new abbreviations by your guideline 'abbreviate the English translation of the usual phrase used by native speakers' or 'take the first three letters of an English place name identifying each zone'. Also, as this timezone was split off from 'Asia/Novosibirsk', it should have same abbreviations as it has before split / time switch. Look into 'Europe/Riga' as an example. -- Regards, Pavel.

In my opinion the abbreviations problem should be faced from a different perspective. I think the point isn’t who invented a particular abbreviation or whether it is available or not on English-language tzdata-independent sources, but that abbreviations are useful because they provide information that the UTC offsets with which they are now being replaced don’t provide. A very simple example: I could write that my time is 14:09 +02 and this would precisely define it, but if I wrote that my time is 14:09 CEST then, if you care, you would also know that I’m writing from Central Europe and not from Egypt, from Central Africa, from South Africa, or from the Kaliningrad Oblast in Russia. Using abbreviations when specifying times isn't obligated (i.e. if you don’t like them you can omit them), but I would say that it is undeniable that their indication makes world times easier to read and quicker to identify since abbreviations link times to geographic regions. If this weren’t so, time zone names (e.g. Central Europe Time, Pacific Standard time, … ) wouldn’t have been introduced and tzdata wouldn’t have included abbreviations in its data. Admitted that time zone names (and their abbreviations) have their usefulness, I think that all TZ ids should be treated in the same way and should deserve an abbreviation. The fact that NOVT or KRAT were invented didn’t make them less useful. Barbara Canino

... if I wrote that my time is 14:09 CEST then, if you care, you would also know that I'm writing from Central Europe and not from Egypt, from Central Africa, from South Africa, or from the Kaliningrad Oblast in Russia.
Yes, but this doesn't hold up across the entire database. Consider CST might mean Central Standard Time, China Standard Time, Cuba Standard Time, etc. BST might mean British Summer Time, Bangladesh Standard Time, etc... It only really works when the user has some other context, such as foreknowledge of country. -Matt

You’re perfectly right and I’m aware of this. But even if there are abbreviations that correspond to different time zone names, I think that abbreviations are useful and should be provided for all TZ ids. Barbara
On Jun 3, 2016, at 6:48 PM, Matt Johnson (PNP) <matt.johnson@microsoft.com> wrote:
... if I wrote that my time is 14:09 CEST then, if you care, you would also know that I’m writing from Central Europe and not from Egypt, from Central Africa, from South Africa, or from the Kaliningrad Oblast in Russia.
Yes, but this doesn't hold up across the entire database. Consider CST might mean Central Standard Time, China Standard Time, Cuba Standard Time, etc. BST might mean British Summer Time, Bangladesh Standard Time, etc...
It only really works when the user has some other context, such as foreknowledge of country.
-Matt

On Fri, Jun 3, 2016, at 01:49, Paul Eggert wrote:
I certainly don't think "The US and Europe get abbreviations and Russia does not" is reasonable.
Quite right, the guideline should not pick on Russia, and that's not the intent.
The intent matters less than the effect. But in this case, the *intent* seems quite clearly to be to favor English-speaking countries (or countries whose timezones are more frequently talked about *in* English, e.g. Western Europe) over non-English-speaking ones, otherwise we would eventually use the numeric names everywhere rather than stating there are no plans to remove [e.g.] EST.

On 06/03/2016 07:16 AM, Random832 wrote:
the*intent* seems quite clearly to be to favor English-speaking countries
Quite true; tzdata itself has always been English-language, and this favors English-speaking countries. That is why Europe/Berlin uses CEST (the English-language abbreviation for Central European Summer Time) and not MESZ (the German abbreviation for Mitteleuropäische Sommerzeit) for its abbreviation now. Users who want a German translation are encouraged to use CLDR, which addresses that sort of thing. This bias for English in general and a North American time zone abbreviation style in particular comes the API's original design. 7th Edition Unix (1979) supported only English and as shipped ran in US Eastern time with US daylight-saving rules hard-coded in C; if you wanted to run in a different time zone you had to change some code and recompile the system. The 7th Edition 'date' program used the format of "Sat Jan 15 19:23:42 EST 1977" because it was easy in those circumstances. Had the 'date' program not bothered to output the time zone abbreviation, tz and POSIX and ISO C quite probably wouldn't have tried to specify how abbreviations are generated, and we wouldn't have the abbreviation mess we have now. In 7th Edition Unix the "EST" in the above example came from a hard-coded table that had only the five main North American zones (standard and daylight) plus GMT. For what it's worth, if you change 7th Edition's TIMEZONE to Tomsk's time zone and its DSTFLAG to 0 and recompile everything, the 7th Edition 'date' command outputs "Sun Jan 16 07:23:42 GMT+7:00 1977", which is similar in spirit to the "Sun Jan 16 07:23:42 +07 1977" that is output by tzdata 2016d's 'date' command when TZ='Asia/Tomsk'.

Date: Thu, 2 Jun 2016 13:54:05 -0700 From: Paul Eggert <eggert@cs.ucla.edu> Message-ID: <2ae93448-8529-f99c-c8f1-781df9e72fee@cs.ucla.edu> | and this unexpected aspect of our invented abbreviations | can easily confuse non-experts. This I wholly support - but with the opposite conclusion than you arrive at. Absolutely anything we can do in the abbreviation field to have it cause problems to anyone who attempts to do anything with it other than display it to users, we should do. Create ambiguities, ... all of that is a good thing. We need to stop software (or specifications) attempting to treat the abbreviation as input data for anything at all. kre

Paul Eggert wrote: [dd]
Another problem with abbreviations like NOVT is that their meanings change with time. For example, NOVT stands for +06 now, but it stands for +07 before October 2014, for +06 again before March 2011, etc. The ambiguity of "NOVT" is atypical for English-language time zone abbreviations, and this unexpected aspect of our invented abbreviations can easily confuse non-experts.
In contrast, abbreviations like +06 and +07 are unambiguous.
For once in a while I agree with your argument. This is the same reason I don't quite like the idea of calling Russian timezones "MSK+4", "MSK-1" etc because the Moscow time itself is fickle: its UTC offset has changed several times with the introduction and abolishment of the decree time.
So remove the feature entirely.
That's not a practical option, as time zone abbreviations are a standard part of ISO C, of POSIX, and of many programming systems that use a tzcode-like interface, so we need to put *something* in there. Numeric abbreviations are reasonable placeholders for zones lacking well-supported English-language time zone abbreviations.
I suggest a compromise: don't remove what's already there (like KRAST), but don't invent any new abbreviations. Even if the original source of "KRAST" is tzdata itself, it has already taken root elswhere. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov@sibptus.tomsk.ru

03.06.2016 в 03:16:15 +0700 Pavel V. Rochnyack написал:
02.06.2016 22:37, Paul Eggert wrote:
Another reason for not using these abbreviations, which I haven't perhaps made clear, is to avoid arbitrating disputes over what the time zone abbreviations should be. A user could reasonably complain "Why are you making up an abbreviation that calls it Krasnoyarsk Time? This is Tomsk, not Krasnoyarsk!" The current kerfuffle is just the tip of the iceberg, and the problem will get worse as the number of tzdata names increases.
There is the same cities (Novosibirsk / Krasnoyarsk) in timezones on Android and Windows OS (and there are a lot of users of these OS), so you can treat these as common-used names for timezones.
I suppose what this argument, together with the previously listed arguments, is enough to set abbreviations in 'Asia/Tomsk' to NOVT/KRAT like already done in 'Asia/Novokuznetsk'.
Also please note what 'Asia/Novokuznetsk' uses not only similar schema of 'to take abbreviations from nearby timezone' but the same timezones.
And which one of the NOVT and KRAT should be used when both Novosibirsk and Krasnoyarsk will be in the same time zone? (This will likely be the case by the end of this year.)

03.06.2016 4:25, Stepan Golosunov пишет:
Also please note what 'Asia/Novokuznetsk' uses not only similar schema of 'to take abbreviations from nearby timezone' but the same timezones.
And which one of the NOVT and KRAT should be used when both Novosibirsk and Krasnoyarsk will be in the same time zone? (This will likely be the case by the end of this year.)
In that case, for 'Asia/Tomsk' you should use the same naming as for 'Asia/Novokuznetsk'. So, assigning NOVT/KRAT abbreviations to 'Asia/Tomsk' does not add new problems. Also, as this timezone was split off from 'Asia/Novosibirsk', it should have same abbreviations as it has before the time switch. -- Regards, Pavel.

Paul Eggert wrote:
On 06/02/2016 01:11 AM, Victor Sudakov wrote:
Sources like the ones below are not good enough?
No, not at all. The Wikipedia page is derived from tzdata, and is not a reliable source is its own right.
Paul, What is a reliable source for you? If you need proof that these abbreviations are in active use, here was the proof.
The other sources are not English-language.
You must be kidding me. Why would you demand English-language sources to illustrate the use of timezone abbreviations by Russians and on Russian sites? However, the https://savvytime.com/converter/btt-to-krat link I had given earlier *is* in English, isn't it? Anyway, you can google for "OMST KRAST" and find lots of uses, in any language you like. Please don't fix which is not broken. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov@sibptus.tomsk.ru

On 06/02/2016 08:00 AM, Victor Sudakov wrote:
Why would you demand English-language sources to illustrate the use of timezone abbreviations by Russians and on Russian sites?
However, thehttps://savvytime.com/converter/btt-to-krat link I had given earlier*is* in English, isn't it?
Ah, sorry, I misread them. Still, all the sources that you mention are derived from tzdata; they are not independent sources for the abbreviations. And they do not really care what the abbreviations are; they just use what tzdata outputs. I am looking for English-language sources that are independent from tzdata.

02.06.2016 22:02, Paul Eggert пишет:
On 06/02/2016 08:00 AM, Victor Sudakov wrote:
Why would you demand English-language sources to illustrate the use of timezone abbreviations by Russians and on Russian sites?
However, thehttps://savvytime.com/converter/btt-to-krat link I had given earlier*is* in English, isn't it?
Still, all the sources that you mention are derived from tzdata; they are not independent sources for the abbreviations. And they do not really care what the abbreviations are; they just use what tzdata outputs.
I am looking for English-language sources that are independent from tzdata.
It is a bit strange to expect the availability of own (not invented by you) English-language abbreviations in countries with non-latin alphabet. Especially when tzdata database is exists and widely-used as it is good enough for this. -- Regards, Pavel.

On Thursday, June 2 2016, "Paul Eggert" wrote to "Victor Sudakov, Time zone mailing list" saying:
On 06/02/2016 01:11 AM, Victor Sudakov wrote:
Sources like the ones below are not good enough?
No, not at all. The Wikipedia page is derived from tzdata, and is not a reliable source is its own right. The other sources are not English-language.
For non-English-speaking places that nonetheless have a standard name for their time zone, I think an English calque of the commonly-used name or abbreviation in the local language is a better choice than giving up entirely. (Much as we use "CET" for "Mitteleuropäische Zeit / MEZ".) It certainly sounds like the common usage in Russia (and in the Soviet Union back in the day) is to call the timezones МСК−1 through МСК+9, which would be calqued as MSK-1 through MSK+9. This is what I'd recommend for Russian timezones, unless actual Russians disagree. -- Jonathan Lennox lennox@cs.columbia.edu

On Thu, Jun 2, 2016, at 11:02, Jonathan Lennox wrote:
It certainly sounds like the common usage in Russia (and in the Soviet Union back in the day) is to call the timezones МСК−1 through МСК+9, which would be calqued as MSK-1 through MSK+9. This is what I'd recommend for Russian timezones, unless actual Russians disagree.
The objection to this (and to using "UTC+nn" for other timezones) has been that someone or some code might mindlessly copy an output timezone abbreviation into TZ, resulting in (from MSK+2) a timezone which is called "MSK" and has an offset of -02:00. I don't recall if anyone's provided any concrete evidence of such a thing actually happening. [Incidentally, what should these use for daylight saving time? MSD itself isn't as "standard" as MSK, but is well entrenched in the Unix world. Or, not being constrained to three characters, use "MSK[+nn]DST" or "MSKDST[+nn]"?]

Just to reiterate, the objection is that I think parsing software in general will interpret something like MSK+nn and interpret it as a TZ variable timezone, or interpret it something like that, but with the sign flipped, and I did give an example of where this would come up (python-dateutil). Using a scheme like this a date that says "2015-06-02 11:31:46 EDT+4" could be interpreted as meaning "EDT, which is UTC+4", "EDT, which is UTC-4" (POSIX), or "A time zone with no specified abbreviation that is 4 hours ahead of EDT." Since the last one of these is not really something you can parse into a time zone unless you know that EDT+4 is a specific time zone abbreviation and what the "EDT" refers to, most software will likely default to parsing as one of the other two interpretations (which would be wrong). That said, if "MSK-1" is the name of the time zone that people actually use, the fact that it is not an essentially machine-readable format should not preclude its inclusion in tzdata. python-dateutil will naively parse this as "MSK, which is 1 hour ahead of UTC", but if you know that "MSK-1"->"MSK-9" is a possibility, you can specify a mapping between those strings and the correct time zone when parsing. I imagine other date parsers have a similar strategy to resolve such ambiguities. On June 2, 2016 11:31:46 AM EDT, Random832 <random832@fastmail.com> wrote:
On Thu, Jun 2, 2016, at 11:02, Jonathan Lennox wrote:
It certainly sounds like the common usage in Russia (and in the Soviet Union back in the day) is to call the timezones МСК−1 through МСК+9, which would be calqued as MSK-1 through MSK+9. This is what I'd recommend for Russian timezones, unless actual Russians disagree.
The objection to this (and to using "UTC+nn" for other timezones) has been that someone or some code might mindlessly copy an output timezone abbreviation into TZ, resulting in (from MSK+2) a timezone which is called "MSK" and has an offset of -02:00. I don't recall if anyone's provided any concrete evidence of such a thing actually happening.
[Incidentally, what should these use for daylight saving time? MSD itself isn't as "standard" as MSK, but is well entrenched in the Unix world. Or, not being constrained to three characters, use "MSK[+nn]DST" or "MSKDST[+nn]"?]

02.06.2016 21:41, Paul Eggert пишет:
On 06/02/2016 01:11 AM, Victor Sudakov wrote:
Sources like the ones below are not good enough?
No, not at all. The Wikipedia page is derived from tzdata, and is not a reliable source is its own right. The other sources are not English-language.
https://flightaware.com/live/airport/UNKL https://savvytime.com/converter/btt-to-krat http://www.timeanddate.com/time/zones/krat I'm sorry to bother you, but what language they are? Also, the presence of these abbreviations use in non-English language only emphasizes wide use of the term. -- Regards, Pavel.

On Thu, Jun 2, 2016, at 10:41, Paul Eggert wrote:
On 06/02/2016 01:11 AM, Victor Sudakov wrote:
Sources like the ones below are not good enough?
No, not at all. The Wikipedia page is derived from tzdata, and is not a reliable source is its own right. The other sources are not English-language.
Wikipedia uses "USZ1", which has never appeared in tzdata, for Kaliningrad.

Paul Eggert wrote:
On 06/02/2016 01:11 AM, Victor Sudakov wrote:
Sources like the ones below are not good enough?
No, not at all. The Wikipedia page is derived from tzdata, and is not a reliable source is its own right. The other sources are not English-language.
Windows uses abbreviations like RTZ6 for Russian timezones. Is Microsoft a reliable independent English-language source in your opinion? Maybe tzdata should adopt those abbreviations, they look fine to me at first glance, at least much better than pure numerics. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov@sibptus.tomsk.ru

Windows uses abbreviations like RTZ6 for Russian timezones.
We removed those in April's update. https://support.microsoft.com/en-us/kb/3148851 https://blogs.technet.microsoft.com/dst2007/2016/03/15/time-zone-updates-for... Basically, someone (not me) thought it would be a good idea to number the zones - but it became apparent later that it just added to the confusion because there were some Russian zones with numbers and some without them. We added more with the recent zone splits, so they really don't make sense for us.
Maybe tzdata should adopt those abbreviations...
If they were, more than one IANA zone might be sharing the same RTZ number, and that still doesn't address the periods when DST was being used. Also, since the number of zones has changed over the years, it would be really weird to see RTZ11 during a period when there were only 9 zones. (See https://en.wikipedia.org/wiki/Time_in_Russia ) I'm not sure what the answer is, but I recommend against using RTZ# style abbreviations. Matt Johnson Microsoft

Matt Johnson (PNP) wrote:
Windows uses abbreviations like RTZ6 for Russian timezones.
We removed those in April's update. https://support.microsoft.com/en-us/kb/3148851 https://blogs.technet.microsoft.com/dst2007/2016/03/15/time-zone-updates-for...
I don't quite understand what you removed, my Windows 7 tray clock still shows something like "(UTC+07:00) Krasnoyarsk (RTZ 6)" in the timezone settings. But if you (from the microsoft.com domain) say that
I'm not sure what the answer is, but I recommend against using RTZ# style abbreviations.
I must accept your word as final. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov@sibptus.tomsk.ru

I don't quite understand what you removed, my Windows 7 tray clock still shows something like "(UTC+07:00) Krasnoyarsk (RTZ 6)" in the timezone settings.
We changed that display string to remove the "(RTZ 6)" portion. If you're still seeing it, then likely then you don't have Windows Update turned on, or for whatever reason have not installed this update. Just like IANA pushes out updates to tzdata, Windows also keeps time zone data updated. In fact, we have a very large update coming out later this month that will align Windows to be much closer to IANA data - at least in terms of covering every populated region on the planet, and correcting past inaccuracies. For more details see: https://blogs.technet.microsoft.com/dst2007/2016/06/02/introducing-new-windo... We still consider IANA to be a superior data set though, and several groups at Microsoft are working on moving towards migrating. For example, WinRT / UWP apps have already been using IANA data for awhile now, and .NET Core on Linux/OSX uses the OS-provided tzdata files. -Matt

On Fri, Jun 3, 2016, at 01:34, Matt Johnson (PNP) via tz wrote:
If they were, more than one IANA zone might be sharing the same RTZ number
...*that's the point*. Time zone abbreviations aren't supposed to identify IANA zones, they're supposed to identify real present-day timezones. Just like more than one IANA zone shares EST. This is a feature, not a bug.

If they were, more than one IANA zone might be sharing the same RTZ number
...*that's the point*. Time zone abbreviations aren't supposed to identify IANA zones, they're supposed to identify real present-day timezones. Just like more than one IANA zone shares EST. This is a feature, not a bug.
Perhaps for IANA, if those are used in the abbreviation fields, I can understand that. However for Windows it didn't make sense because it was part of the primary zone display name. Similar to if IANA put them in the zone name directly. I'd still want to be sure that these are not invented terms. So would you recommend then that when Russia moved from 11 zones to 9 zones and back to 11 that the zones would be renumbered to correspond with those changes? (eg, RTZ5 becoming RTZ6?) And if so, is that what people in the region would have agreed with at the time? Would they have said "we were in the 5th time zone, now we're in the 6th time zone" (in Russian) ? -Matt

Matt Johnson (PNP) via tz wrote:
So would you recommend then that when Russia moved from 11 zones to 9 zones and back to 11 that the zones would be renumbered to correspond with those changes? (eg, RTZ5 becoming RTZ6?) And if so, is that what people in the region would have agreed with at the time? Would they have said "we were in the 5th time zone, now we're in the 6th time zone" (in Russian) ?
As far as I am concerned, people in Russia and in Russian mostly use the offset from MSK to refer to their timezone. So people in Tomsk say "We have been in the MSK+3 zone and now we are in the MSK+4 zone". Sometimes we also refer to timezones by their major city, like "Novosibirsk time". Offset from UTC is not popular with the public here, unless you are an engineer of some kind, or an amateur radio operator etc. -- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov@sibptus.tomsk.ru

03.06.2016 в 12:05:40 +0700 Victor Sudakov написал:
Paul Eggert wrote:
On 06/02/2016 01:11 AM, Victor Sudakov wrote:
Sources like the ones below are not good enough?
No, not at all. The Wikipedia page is derived from tzdata, and is not a reliable source is its own right. The other sources are not English-language.
Windows uses abbreviations like RTZ6 for Russian timezones. Is Microsoft a reliable independent English-language source in your opinion?
Maybe tzdata should adopt those abbreviations, they look fine to me at first glance, at least much better than pure numerics.
The number in RTZ6 is just an ordinal number of time zone as listed in the law. And these numbers were changed in 2014 (RTZ5 became RTZ6 while RTZ1 remained RTZ1). And before 2011 there were time belts, which were numbered according to their UTC offsets (0 to 23 starting with the Greenwich meridian according to 1919 decree). Except since 1930 one had to add extra hour to that number for the decree time. And many regions were officially in one time belt but were using time from another. AFAIK, time zones in Russia do not have names (except for Moscow time). Everyone is referring to them by whatever representative location he chooses. (Moscow time is currently defined in the law as the "time of the time zone where Moscow is located".)

02.06.2016 13:59, Paul Eggert пишет:
Victor Sudakov wrote:
But these abbreviations are already sanctified by a long tradition.
Not really. And I have some experience in this, as I am the one who *invented* that "long tradition", and I've seen it not catch on.
When are you planning to migrate the abbreviations like EST or HST? EST and HST have been commonly used by reliable English-language sources for decades. We did not invent these abbreviations, and don't plan to remove them.
These abbreviations says nothing for most of us in Russia like our Russian abbreviations (MSK/SAMT/YEKT/OMST/KRAT/IRKT/YAKT/VLAT/MAGT) says nothing for people around you. But that is not a reason to ask you to remove EST / HST from tzdata database, right? I do not see anything good in the proposed segregation when you leave EST / HST in use but take away NOVT / KRAT and other russian timezone abbreviations.
Nobody here in Tomsk calls our timezone "+07" in practice, I assure you. That's just another invention
Yes, I wouldn't expect people in Tomsk to use English-language abbreviations. They would use Russian-language abbreviations, if anything.
Technically we have no need in Russian-language abbreviations in most of cases. But there exists need in English abbreviations. People are smart enough to use English-language abbreviations and these abbreviations are widely-used at practice.
Yes, the idea is to use an English-language abbreviation if there is one in common use, and to fall back on a numeric abbreviation otherwise.
How are you going to determine if English-language abbreviation is in common use or not? As noticed by Victor, abbreviations like 'NOVT' and 'KRAT' and others listed above are commonly used. That is the fact, regardless of who were invented these abbreviations. I would also like to note that despite the fact that only Victor writes in this maillist, it is readed by many people at the moment. We would not want to transform the mailing list into the voting list. -- Regards, Pavel.

Date: Wed, 1 Jun 2016 23:59:57 -0700 From: Paul Eggert <eggert@cs.ucla.edu> Message-ID: <574FD96D.60403@cs.ucla.edu> | And I have some experience in this, as I am the one who *invented* | that "long tradition", and I've seen it not catch on. Actually, I suspect that in many cases you're wrong - some of the abbreviations that are in use were certainly invented by the TZ project, and hence, all uses of them will source back to tzdata eventually, but regardless of that, since they have now been around so long, they have become the standard timezone name abbreviations, as much as any such thing exists. I know that the one for Thailand (Asia/Bangkok) (ITC) was an invention, but now it is in quite widespread use (and in a country with only one zone, and hence no real need for names at all, that's remarkable.) It really is too late now to wish that the abbreviations had not been invented, or to wonder how anyone here got the right to do that - sometimes things just happen - but afterwards, they're just as entrenched as anything else. I also don't really think it rational to penalise areas that don't commonly use English and hence aren't likely to have English abbreviations, while allowing the English speaking world to do as they like. kre

On 06/02/2016 09:24 AM, Robert Elz wrote:
I know that the one for Thailand (Asia/Bangkok) (ITC) was an invention
I assume you mean "ICT" for Indo-China Time. Yes, ICT is another invention of mine. However, it has caught on more, in the sense that it is much better-supported among reliable English-language sources. Another difference is that ICT corresponds to a time zone region that crosses political boundaries (the abbreviation is used for Cambodia, Laos, and Vietnam too), and this insulates us better from political disputes.

Date: Thu, 2 Jun 2016 09:42:59 -0700 From: Paul Eggert <eggert@cs.ucla.edu> Message-ID: <5500329f-45ce-b123-7185-7b85e0914a06@cs.ucla.edu> | On 06/02/2016 09:24 AM, Robert Elz wrote: | > I know that the one for Thailand (Asia/Bangkok) (ITC) was an invention | | I assume you mean "ICT" for Indo-China Time. Yes, a typo, sorry... kre

On 05/25/2016 07:35 AM, Victor Sudakov wrote:
1. zic warns that 'warning: time zone abbreviation differs from POSIX standard (+06)'
That warning is incorrect nowadays, as POSIX allows numeric time zone abbreviations like '+06'. Older versions of zic generate a warning for numeric abbreviations because POSIX.1-1988 did not specify support for them. However, POSIX.1-2001 added them, and zic 2015f (and later) uses the 2001 POSIX rules and so does not issue that warning.
2. Such an abbreviation is not user friendly and even borders on offensive. A locality deserves a name!
The trend is more in the other direction, as we are planning to convert more zones to use numeric offsets instead of using English-language abbreviations that are merely our invention. The idea is that the tz database should reflect common practice, not impose it. We started this with new zones like Asia/Tomsk in order to check for problems due to backward compatibility with pre-2001 software. So far, these problems have not materialized, so we have continued this with longstanding zones like Asia/Almaty. More work remains to be done, of course. It has been suggested that we discard invented abbreviations all at once rather than a few at a time. This would take a burst of effort, though.

Paul Eggert wrote: [dd]
2. Such an abbreviation is not user friendly and even borders on offensive. A locality deserves a name!
The trend is more in the other direction, as we are planning to convert more zones to use numeric offsets instead of using English-language abbreviations that are merely our invention. The idea is that the tz database should reflect common practice, not impose it. We started this with new zones like Asia/Tomsk in order to check for problems due to backward compatibility with pre-2001 software. So far, these problems have not materialized, so we have continued this with longstanding zones like Asia/Almaty. More work remains to be done, of course.
Dear Paul, I did not know about this trend, but now that I know, it saddens me. For example, in FreeBSD's tzsetup(8) in the interactive mode, the numeric abbreviation looks unsightly, though probably harmless.
It has been suggested that we discard invented abbreviations all at once rather than a few at a time. This would take a burst of effort, though.
-- Victor Sudakov, VAS4-RIPE, VAS47-RIPN sip:sudakov@sibptus.tomsk.ru
participants (14)
-
Barbara Canino
-
Guy Harris
-
Ian Abbott
-
Jonathan Lennox
-
Matt Johnson (PNP)
-
Paul Eggert
-
Paul G
-
Paul Goyette
-
Pavel V. Rochnyack
-
Random832
-
Robert Elz
-
Stepan Golosunov
-
Steve Allen
-
Victor Sudakov