Sorry, but let me put in my two cents... On 04/03/2015 10:51 PM, Lester Caine wrote:

This is a debate we had on the tzdist workgroup. A rule set can be used by many timezones, and as such is generic to the TZ database, not a specific tz identifier. CET for example is used by numerous central European identifiers, as are many of the American rule sets. In the American example, states may switch between one rule set and another over time resulting in a complex set of timezone data, but the rule set itself does not change.

The key concept here is that "the rule itself doesn't change". I don't believe MSK can be considered a rule set in that sense (and hence a generic rule set) like CET and American time zones are, since it has a history of changing its rules directly following change of time keeping policies in certain region of a certain country. And I am strongly convinced that everyone understands that it will be changed again should the region it denotes in its name change its time keeping policies yet again. I also believe that a rule set to be considered generic should not be named after a place in one particular country of the region it represents and should be a neutral term without bias towards any country in that region and that its name or usage shouldn't spark any political debates or be completely denied by any of the countries it is considered to be observed in. Please correct me if I'm being wrong here. Belarus is currently using the same rule set it

was using pre-1970? We do not need to duplicate that rule set and create a new identifier for it ... we just use the generic rule set that works.

Technically, there was no such country as Belarus pre 1991, hence Belarus couldn't have used MSK, the record of Minsk using MSK pre 1990 merely represents the fact that it was part of a "Moscow time" using region of the Soviet Union which now and for the last 25 years it isn't. Moreover there was no need to create anything since Belarus already had its UTC+3 time zone abbreviation before MSK rule was changed from UTC+4 to UTC+3. And above is my explanation why I believe that MSK can not be considered a generic rule set. I would agree with one rule set - one name policy if it was strictly observed by the TZ database. However I can see numerous instances of using different abbreviations for the exact same rules in neighbouring regions in different countries and here are just couple examples of the countries used to be part of the Soviet Union like Belarus did: * [UTC+5 all year round] Russia("Asia/Yekaterinburg") uses YEKT and neighbouring Kazakhstan("Asia/Oral") uses ORAT and another neighbour Turkmenistan("Asia/Ashgabat") uses TMT; * [UTC+6 all year round] Russia("Asia/Novosibirsk"): NOVT, Kazakhstan("Asia/Almaty"): ALMT I just don't see why Belarus is denied (and even deprived of) its own time zone name in similar situation. -- Dzmitry Kazimirchyk

On 04/04/2015 01:03 AM, Paul Eggert wrote:

The situation with MSK is not unprecedented. For example, in the tz database PST stands for "Pacific Standard Time" in the United States, and for "Pitcairn Standard Time" in Pitcairn, and corresponds to UTC-8 in both countries. This is entirely analogous to MSK standing for "Moscow time" in Russia and for "Minsk time" in Belarus and corresponding to UTC+3 in both countries. For timekeeping purposes it's often a bit simpler to use the same abbreviation for the same UTC offset even if the abbreviation is ambiguous, and this hasn't been a significant technical problem in practice.

I don't believe that MSK situation is similar to PST since I can see both Pacific Standard Time and Pitcairn Standard Time in the list here: http://www.timeanddate.com/time/zones/ meaning that they both are publicly known. But I fail to see MSK there or somewhere else (even in the TZ database itself) mentioned as "Minsk time" at all. And I will repeat that due to the aforementioned reasons by using MSK TZ database imposes the term of "Moscow time" to describe time in Belarus which wouldn't take place otherwise. I also urge you not to downplay the role of time zone abbreviations in the TZ database, due to their vast usage in software in general and in particular to display formatted dates. -- Dzmitry Kazimirchyk

On 04/04/2015 02:32 AM, Guy Harris wrote:

But if you don't want them downplayed, please suggest an abbreviation to use for Minsk time.

Since there is no official or habitual abbreviation in use as I've mentioned before, I assume it will be right to use the standard approach mentioned in this discussion previously which suggested either MINT or BYT. I assume MINT is more correct abbreviation for "Minsk time", so I personally would pick this one. -- Dzmitry Kazimirchyk

+1 from me, unless there's a compelling reason to use something other than MINT; I haven't heard any that I consider compelling.

We're okay with MINT for Minsk Time as long as North Dakota doesn't adopt a unique scheme.-) http://en.wikipedia.org/wiki/List_of_cities_in_North_Dakota#Cities @dashdashado On Fri, Apr 3, 2015 at 8:58 PM, Guy Harris <guy@alum.mit.edu> wrote:

On Apr 3, 2015, at 4:44 PM, Dzmitry Kazimirchyk <dkazimirchyk@gmail.com> wrote:

...

On 04/04/2015 02:32 AM, Guy Harris wrote:

...

But if you don't want them downplayed, please suggest an abbreviation to use for Minsk time.

Since there is no official or habitual abbreviation in use as I've mentioned before, I assume it will be right to use the standard approach mentioned in this discussion previously which suggested either MINT or BYT. I assume MINT is more correct abbreviation for "Minsk time", so I personally would pick this one.

+1 from me, unless there's a compelling reason to use something other than MINT; I haven't heard any that I consider compelling.

On 1 April 2015 at 19:07, Paul Eggert <eggert@cs.ucla.edu> wrote:

On 04/01/2015 01:09 PM, Tim Parenti wrote:

...

I cannot think of another case where we have applied the designation of a neighboring country to a region that has not itself changed its timekeeping rules.

The situation here is not unprecedented. The tz database used MSK/MSD for Europe/Minsk at UTC+3/4 even after Belarus's independence from the Soviet Union in July 1990. And this continued a longstanding practice of using MSK/MSD to denote Minsk time at UTC+3/4, going all the way back to 1930. The conservative approach here is to continue to use the same abbreviation.

This doesn't really address my inquiry, which was aimed at identifying other areas of the world where similar situations have occurred. Soviet-era history aside (MSK is clearly appropriate there), the period of roughly one year before Belarus adopted independent timekeeping in September 1991 is not a particularly compelling point. Moreover, if using MSK to denote Minsk time at UTC+3/4 has been "longstanding practice", why didn't we refer to Minsk Time as MSK instead of FET in 2011–2014? The (hopefully obvious) answer is the ambiguity caused by its geographic proximity to Moscow, which was behaving differently. (It also happens to be a politically charged issue, but proximity alone has been enough to disambiguate before; see AEDT, etc.) On 3 April 2015 at 18:03, Paul Eggert <eggert@cs.ucla.edu> wrote:

The situation with MSK is not unprecedented. For example, in the tz database PST stands for "Pacific Standard Time" in the United States, and for "Pitcairn Standard Time" in Pitcairn, and corresponds to UTC-8 in both countries. This is entirely analogous to MSK standing for "Moscow time" in Russia and for "Minsk time" in Belarus and corresponding to UTC+3 in both countries. For timekeeping purposes it's often a bit simpler to use the same abbreviation for the same UTC offset even if the abbreviation is ambiguous, and this hasn't been a significant technical problem in practice.

I would argue that the large distance between the areas covered by Pacific Standard Time and Pitcairn Standard Time make this very different from the cases of Minsk Time and Moscow Time here, which abut. On 2 April 2015 at 07:26, Dzmitry Kazimirchyk <dkazimirchyk@gmail.com> wrote:

If hypothetically Russia will announce time zone rules change putting Moscow back to UTC+4 again, what will change in TZ database: MSK time zone rules or time zone for the Russia's Moscow region? I assume in this case Belarus even if staying at UTC+3 will not remain in MSK time zone and MSK rules will be changed instead, like it already happened in the past.

Although reasoning about hypotheticals often breaks down, this concerns me as well. If Moscow futzes with its clocks five times in the next decade, changing our reckoning MSK along with it, while Minsk leaves its clocks alone, does it really make sense to change Minsk's abbreviation five times? What if Moscow only futzes three times? What if just the once? While we shouldn't be quick to create new designations, we created FET for convenient grouping and it was selected because it was "unambiguous": http://mm.icann.org/pipermail/tz/2011-September/008837.html On 3 April 2015 at 19:32, Guy Harris <guy@alum.mit.edu> wrote:

But if you don't want them downplayed, please suggest an abbreviation to use for Minsk time.

MINT and BYT have been repeatedly suggested in this thread, and have much stronger backing from Theory than MSK for this purpose. MINT and BYT were suggested as natural designations for Belarus at the time FET was created, as well: http://mm.icann.org/pipermail/tz/2011-September/008813.html -- Tim Parenti

On 3 April 2015 at 20:28, Paul Eggert <eggert@cs.ucla.edu> wrote:

the large distance between the areas covered by Pacific

...

Standard Time and Pitcairn Standard Time make this very different

They are not different if one excludes political considerations and focuses on timekeeping considerations, which is what we ought to do here.

Politics aside, geographical considerations are also important here and seem to make this more unique.

And there are other examples involving nearby countries sharing abbreviations, e.g., Iraq sharing "AST" with Saudi Arabia, even though Iraq is not in Arabia.

Thanks; this provides some context I was looking for. -- Tim Parenti

Dzmitry Kazimirchyk wrote:

I think AST (a.k.a Arabia Standard Time) in its both full and abbreviated forms is used to denote time in Iraq both locally and internationally and it was not the TZ database who first introduced this tradition.

No, I introduced the abbreviation "AST" for Arabia Standard Time in the 1990s, as part of my contributions to the tz database. As far as I know it was not part of any local or international convention. It seemed like a good idea at the time. Given the controversy over what "MSK" stands for, though, ...

there is a wide agreement that "Minsk time" and "Moscow time" are not the same terms

Yes.

community should have picked the abbreviation as per standard procedure

The dispute here is over what the "standard procedure" is. The guidelines mainly attempt to record the informal thought processes I used while contributing to the tz database since the early 1990s. These processes produced many abbreviations that I invented purely because the database format required *something* even though no abbreviations were actually in common use. Here's an example of what these thought processes produced: since 1998 in the tz database the abbreviation MMT has stood for both "Minsk Mean Time" (in use 1924-1930) and "Moscow Mean Time" (1916-1918). The analogy to MSK should be obvious.

3. I've brought up an example of Kazakhstan

Sure, and Kazakhstan uses (for lack of a better term) an "Asiatic" style, which I invented only because *something* is required there, and which has never really caught on in English-language usage. It's better not to invent more abbreviations like that if we don't have to, as seems to be the case here. (Plus, we wouldn't want to confuse non-expert users into thinking that Minsk is in Asia....)

On Apr 6, 2015, at 4:11 PM, Dzmitry Kazimirchyk <dkazimirchyk@gmail.com> wrote:

Furthermore, TZ database doesn't seem to store full time zone names associated with abbreviations it uses.

Correct. At the time the tz database was created, the only consumers were UN*X systems, and they only had APIs to provide abbreviations.

So I guess the consumers of TZ database data are making these associations themselves using some other sources available to them.

For example, the Unicode Common Locale Data Repository: http://cldr.unicode.org stores both full names and abbreviations, in multiple locales, for at least some "metazones"; "metazones" (which OS X mail's autocorrect seems to think should be "metazoans") are a CLDR concept, roughly corresponding to what most(?) people think of as "time zones", and they have their own mappings from tz database names to metazone names. Those mappings duplicate some information from the tz database, as they have to keep track of changes to the "metazone" to which a particular tz database zone belonged, if the name/abbreviation changed over time.

Dzmitry Kazimirchyk wrote:

I would like for the last time to kindly ask about the main reasoning behind it

To some extent I'm repeating myself, but here goes: Although there is no widely-used English-language abbreviation for Minsk time, the database forces us to put something there. We've used MSK for it in the past and there hasn't been any technical problems with it, and there's not sufficient justification to invent a new abbreviation. Among other things, although Minsk is an unusual case, it's by no means unique: there are other cases of multiple Zones sharing the same abbreviation and UTC offset even though the full zone names differ (PST in Pitcairn and the US) and of a country "stealing" a neighbor's abbreviation (AST in Iraq and Saudi Arabia). More generally, a primary goal of the tz database is to reflect common practice, not to invent it. For example, the next tz release is planned to change an abbreviation used in the United States zone America/Adak, as we invented one abbreviation (HAST) but we have since found that standard practice is to use a different one (HST). Years ago, before I knew better, I invented a lot of abbreviations and put them into the tz database, but that was a questionable practice and we're better off avoiding it when we can, as is the case with both Adak and Minsk.

I am sorry but applying all this to Minsk time is largely questionable and dismisses all the counterarguments from the previous discussion without proper explanation as to why. I apologize, but let me reiterate here too: On 4/23/15 1:42 PM, Paul Eggert wrote:

Although there is no widely-used English-language abbreviation for Minsk time, the database forces us to put something there. We've used MSK for it in the past and there hasn't been any technical problems with it, and there's not sufficient justification to invent a new abbreviation.

MSK was used to denote "Moscow time" which was used in Minsk before 1991, but I thought we have agreed that nowadays the correct term is "Minsk time" and MSK is neither historical nor natural abbreviation for that. Isn't this sufficient enough justification, not even considering the fact that Minsk already had its own abbreviation before Moscow adjusted their clock.

Among other things, although Minsk is an unusual case, it's by no means unique: there are other cases of multiple Zones sharing the same abbreviation and UTC offset even though the full zone names differ (PST in Pitcairn and the US) and of a country "stealing" a neighbor's abbreviation (AST in Iraq and Saudi Arabia).

I actually thought that Arabia in AST represents geographical term Arabian Peninsula (which is also referred to as Arabia) rather than country of Saudi Arabia which is one of the countries located there and its usage for denoting time zone in Iraq is justified by Iraq having significant part of its territory geographically located there. If consider that AST bears its name from Saudi Arabia, these two points are actually contradicting each other: PST is example of two natural abbreviations with different disambiguation, and the AST argument would suggest that time in Minsk should be denoted as "Moscow time" which we already agreed isn't the case.

More generally, a primary goal of the tz database is to reflect common practice, not to invent it. For example, the next tz release is planned to change an abbreviation used in the United States zone America/Adak, as we invented one abbreviation (HAST) but we have since found that standard practice is to use a different one (HST). Years ago, before I knew better, I invented a lot of abbreviations and put them into the tz database, but that was a questionable practice and we're better off avoiding it when we can, as is the case with both Adak and Minsk.

Yes, but I don't see how forcing MSK (a.k.a. Moscow time) on Europe/Minsk is reflecting common practice. I'd rather say it is the opposite of that (since as I've explained earlier in this thread MSK is neither natural nor commonly used abbreviation for "Minsk time"). What I can see however is TZ database inventing a new practice of using "Moscow time" to describe time zone for Belarus. Could you please point to flaws in my reasoning here or tell why these arguments are being dismissed? I am having impression that many of the "for MSK" arguments are invented only to defend the questionable decision made not so long ago. I am sure that all the edge case precedents used here as arguments have counter precedents where exactly the opposite was done. From what I understand Minsk was switched to MSK because of the confusion caused by its historic record of using "Moscow time" back when it was part of another country, as we have figured out in this discussion it isn't the case now, so I don't see any compelling reason to keep using it. After all TZ database is there to give relevant information to people, but I can't see how it is TZ database's mission to confuse (or even offend) locals by telling them that they are using foreign "Moscow time" or to give misleading information about country's time zone name to the non locals. I understand that not being a member of TZ community I might not know certain things about TZ database practices, but am I really the only one finding this whole situation strange? -- Dzmitry Kazimirchyk

On 4/23/15 10:23 PM, Paul Eggert wrote:

On 04/23/2015 11:34 AM, Dzmitry Kazimirchyk wrote:

...

I can't see how it is TZ database's mission to confuse (or even offend) locals by telling them that they are using foreign "Moscow time"

It's not. And this is why the current version of the tz database says that MSK stands for either Minsk or Moscow time. It's true that the abbreviation is ambiguous and that this can cause confusion, but there are lots of ambiguous abbreviations in the tz database (AST, BST, CST, ...) and the resulting confusion is a normal and expected aspect of these abbreviations. It's long been recommended to use numeric offsets like "+0300" to avoid this confusion, and this recommendation applies here as well.

Sorry, but I have already explained why I think it is wrong to compare MSK to AST, BST, CST, etc. To repeat myself, MSK is not a natural abbreviation for "Minsk time" but rather is an attempt to stick already existing foreign abbreviation to it. I can't see any logical explanation in picking first and two last letters of the first word of the term to construct an abbreviation for it, why not use MIN, MNS or MNK then. Neither I see any point in introducing ambiguity where there is no logical background for one to appear. Moreover, as I've previously explained, MSK is known and widely used both locally and internationally as abbreviation to denote "Moscow time" and I don't see how a commentary in TZ database can change this conception, so the confusion and misinformation is inevitable and in fact is happening now with software picking MSK for Minsk from TZ database and disambiguating it as "Moscow Standard Time". I really don't think that TZ database is meant to introduce confusion and claim it as a normal practice when there are numerous reasons to avoid it. On 4/23/15 11:59 PM, Lester Caine wrote:

If one was to start again, then the software would probably not be designed around abbreviations, but it is probably that most early users were more interested in daylight saving changes and ignored the static tz offsets at all. If anything needs 'fixing' it's the need for an abbreviation at all when a location only has a fixed time offset. It IS only you who is trying to read more into the situation than actually exists ... in the absence of a documented answer we just use something to fill the hole, and MSK was correct at a point in history.

But it isn't correct at present. From what I understand the decision was indeed made in the absence of all the facts and answers, but I don't understand why now when the facts and answers are available there is such a strong opposition to reconsidering this decision taking them into account. I don't think reasoning about hypothetical TZ database's future without time zone abbreviations is particularly good argument in this case. It has abbreviations now, software and people see and use them, so unless abbreviations are abolished altogether there is not much point in making parallels to this case, since TZ database has lots of examples of using different abbreviations for the similar time zone offsets. On 4/24/15 2:51 AM, Paul_Koning@dell.com wrote:>

I think what he’s doing is refusing to make any changes whose reasoning is political, which makes sense.

I don't see why political reasoning is brought up over and over again when there is completely apolitical and logical explanation: * MSK is abbreviation for "Moscow time" with a strong history and is commonly used both locally and internationally; * MSK is not tied to a time offset like EST, EEST, etc., but is tied to time zone policies at specific geographical region and changes its offset rules following that region's practices (Minsk (and Belarus) is not part of the region MSK represents); * Minsk (Belarus) time zone is commonly referred to as "Minsk time" (not "Moscow time") both by people and in official sources and media; * MSK is neither natural nor historical or habitual abbreviation for "Minsk time"; * Due to the above, usage of MSK for "Minsk time" is confusing and misleading, hence the abbreviation should be changed. -- Dzmitry Kazimirchyk

On Apr 24, 2015, at 2:25 PM, Paul Ganssle <pganssle@gmail.com> wrote:

I have to say, I was originally very skeptical about this proposal because it seems like it would be political, but if MSK really isn't used locally, it probably shouldn't be in the DB regardless of the political implications, particularly if a identical abbreviation is used elsewhere.

I think that dropping out entirely could work,

"Dropping out" as in "remove Minsk time from the database", which wouldn't work very well for users in Belarus, or "dropping out" as in "don't supply any abbreviation", which wouldn't work very well for those UN*X mechanisms that supply time zone abbreviations: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/time.h.html (note "tzname") http://pubs.opengroup.org/onlinepubs/9699919799/functions/tzname.html (yes, it says The tzset() function shall set the external variable tzname as follows: tzname[0] = "std"; tzname[1] = "dst"; where std and dst are as described in XBD Environment Variables. and "XBD Environment Variables" says TZ This variable shall represent timezone information. The contents of the environment variable named TZ shall be used by the ctime(), ctime_r(), localtime(), localtime_r(), strftime(), mktime(), functions, and by various utilities, to override the default timezone. The value of TZ has one of the two forms (spaces inserted for clarity): :characters or: std offset dst offset, rule If TZ is of the first format (that is, if the first character is a <colon>), the characters following the <colon> are handled in an implementation-defined manner. with the latter being an escape hatch put in for the benefit of the Olson database and code, as it was called back then, so one *could* try arguing that POSIX would not impose any constraints on what we do with tzname[] with a tzdb zone setting, but, in practice, that argument will probably fall on deaf ears).

On Sat, Apr 25, 2015, at 15:10, Guy Harris wrote:

with the latter being an escape hatch put in for the benefit of the Olson database and code, as it was called back then, so one *could* try arguing that POSIX would not impose any constraints on what we do with tzname[] with a tzdb zone setting, but, in practice, that argument will probably fall on deaf ears).

The only argument I have seen for not using e.g. "GMT+03" is that people might paste it into the TZ variable and end up with dates with an abbreviation of "GMT" and an offset of -03:00. Note, though, that almost no other abbreviation, except for a handful defined for North America and Europe and not including MSK, can be used directly as the value of TZ.

<<On Thu, 23 Apr 2015 21:34:36 +0300, Dzmitry Kazimirchyk <dkazimirchyk@gmail.com> said:

I am having impression that many of the "for MSK" arguments are invented only to defend the questionable decision made not so long ago.

I agree. I know that Paul wants to "avoid politics" but in this case he has imposed a very sensitive and inherently political choice, which the "people on the ground" have made it clear to us is undesired. -GAWollman

Dzmitry Kazimirchyk wrote:

I can see both Pacific Standard Time and Pitcairn Standard Time in the list here:

http://www.timeanddate.com/time/zones/

Sure, and that's because timeanddate.com got the Pitcairn abbreviation from us, just as it got many of its other abbreviations from us. We shouldn't use timeanddate.com as a primary source for our abbreviations (that would just be an echo-chamber), nor should we expect timeanddate.com to adjust immediately to a change in the experimental version of the tz commentary that was made just a couple of days ago. Instead, we can give the commentary change some time to propagate, and see what happens. There's no rush. After all, a nice property of the change is that the data entries in the existing stable release already conform to the changed documentation, and that makes for less technical hassle for everybody involved.

I just don't see why Belarus is denied (and even deprived of) its own time zone name in similar situation.

The name is Europe/Minsk and that is not in dispute? I had of cause missed that there are no daylight savings changes now and it is just a fixed offset? In which case there is no reason to be using any abbreviation but UTC+3 anyway? I only view abbreviations as important where there are changes during the year and one has to identify which offset is in use where a date is not provided. The history for Europe/Minsk timezone goes back to 1880 at which time Minsk Mean Time was adopted and the political affiliations since then are not relevant to the historic changes made subsequently. MSK is still the natural choice given that history, but UTC+3 is probably equally valid if there is no plan to follow Russia if they reintroduce daylight saving ... which is the reason put forward for the current choice of offset anyway? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk