Paul, thank you for the informative response. I agree that the most commonly used name for Belarus time zone is indeed "Minsk time". However I don't think your proposed change addresses all the issues here. MSK abbreviation has a long history and is commonly referred to as "Moscow time". See for example: http://www.timeanddate.com/time/zones/msk http://en.wikipedia.org/wiki/Moscow_Time Which I assume isn't going to change in the near future, if will be changed at all. So it introduces certain confusion, and can arguably be considered discriminatory towards the country of Belarus. Having said that I think the most appropriate solution would be to have separate abbreviation for "Minsk time" be it either "FET" or something else like "MNSK". However again I'm not sure how it aligns with IANA policies, and would like to hear your opinion on handling such or similar situations in the past. -- Dzmitry Kazimirchyk On 4/1/15 9:19 AM, Paul Eggert wrote:

On 03/30/2015 08:46 AM, Dzmitry Kazimirchyk wrote:

...

my local timezone is displayed as MSK (Moscow Time) instead of FET (Further Eastearn European Time).

The most common English-language name for UTC+3 in Belarus nowadays seems to be "Minsk time", e.g.:

http://eng.belta.by/all_news/sport/Slovakia-flatten-Switzerland-at-Christmas...

http://eng.belta.by/all_news/sport/MAZ-SPORTavto-manages-12th-place-in-Dakar...

http://www.globalresearch.ca/ukraine-ceasefire-agreement-donbass-conflict-re...

http://www.minskairport.com/minsk-airport-arrivals-online-timetable.html

From 2011 to 2014 a time zone separated EET (UTC+2) from MSK (then UTC+4), and I invented the abbreviation "FET" for this UTC+3 zone. But it's better if the tz database reflects existing practice rather than inventing it, and since we no longer have a strong need for an invented abbreviation I'd rather stop using it. Instead, we can document that "MSK" is now ambiguous, and stands for either Minsk or Moscow time, as in the attached proposed patch.

On 01/04/15 09:25, Julian Cable wrote:

There are systems which unfortunately want to use abbreviations in pick lists. Ambiguous abbreviations are not ideal.

They're out of luck then. It didn't take much hunting to discover that BST (British Summer Time) is also used for Pacific/Bougainville. $ TZ=Europe/London date Wed 1 Apr 13:29:25 BST 2015 $ TZ=Pacific/Bougainville date Wed 1 Apr 23:29:31 BST 2015 jch

On 04/01/2015 06:40 AM, Dzmitry Kazimirchyk wrote:

MSK stands for first three consonants of word Moscow transliterated from Russian (MoSKva)

I'm not sure about that theory. If it were so, the English-language abbreviation would be "MSC", not "MSK", since English text almost invariably uses the spelling "Moscow". And that theory wouldn't explain "MSD" either. I expect the actual etymology was more complicated. Regardless of the original etymology, in English "MSK" is a more-natural acronym for Minsk than it is for Moscow, and it has the advantage of being recognized as an alias for UTC+3 by a reasonably large set of software already (which is unwise, but there it is). The tz database is already on record as saying that time zone abbreviations are ambiguous and that software cannot reliably infer UTC offsets from the time zone abbreviations (e.g., "IST" stands for both India and Israel standard time). The ambiguity of "MSK" is merely about location, not about both location and UTC offset, so it is more benign than ambiguities that have longstanding precedents in the database.

<<On Wed, 01 Apr 2015 22:37:36 +0300, Dzmitry Kazimirchyk <dkazimirchyk@gmail.com> said:

If it is an official IANA position on the matter, I am very disappointed. It is pretty much ignoring the fact of existence of sovereign time zone name of one country in favour of another countries' name. Having in mind the fact that it is "Moscow time" time which had its rules changed from UTC+4 to UTC+3 and not "Minsk time" which stayed the same, it makes this thing look even more biased.

The normal convention for zones that do not have a conventional English-language initialism is to use either three letters of the city plus "T", or the ISO 3166-2 alpha-2 code plus "T" -- so the expectation would be that Minsk would get either "MINT" or "BYT". I don't believe that IANA has an official position here; IANA hosts the database but does not maintain it. -GAWollman

On Wed, 01 Apr 2015, Dzmitry Kazimirchyk wrote:

The main problem here is with MSK being both historically and nowadays widely known as "Moscow time" and absolutely zero public awareness of the fact that now it can also mean "Minsk time" in addition to lack of any official sources explaining that.

What time zone abbreviation do people, news media, or official government sources in Belarus use to refer to their time zone? If there is a simple answer, than that's what should go into the tz database. If people on the ground disagree about the abreviation, then we can conduct some sort of popularity survey, as we did with Australia and the EST versus AEST question. If people on the ground don't use any abbreviation, then I suppose the tz project has to guess or invent something. --apb (Alan Barrett)

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

From 2011 to 2014 a time zone separated EET (UTC+2) from MSK (then UTC+4), and I invented the abbreviation "FET" for this UTC+3 zone. But it's better if the tz database reflects existing practice rather than inventing it, and since we no longer have a strong need for an invented abbreviation I'd rather stop using it.

I agree that discontinuing use of FET is the correct approach here. On 1 April 2015 at 14:28, Paul Eggert <eggert@cs.ucla.edu> wrote:

Regardless of the original etymology, in English "MSK" is a more-natural acronym for Minsk than it is for Moscow

Perhaps, but much as we try to say that tz abbreviations are inherently ambiguous, MSK does have a well-established and far-reaching meaning outside the context of our project. Moreover, our own guiding principles would suggest use of BYT (for "Belarus Time") or MINT (for "Minsk Time") before considering anything else. In fact, this is what was first proposed when Belarus switched to year-round UTC+3 in September 2011: http://mm.icann.org/pipermail/tz/2011-September/008813.html Only when Ukraine announced intent to join Belarus on year-round UTC+3 a few days later did we decide to use FET as a convenient method of grouping: http://mm.icann.org/pipermail/tz/2011-September/008833.html http://mm.icann.org/pipermail/tz/2011-September/008837.html (Admittedly, we created FET because we thought at the time that it might become more common and needed a distinct name. In the end, we only grouped Belarus and Kaliningrad, as Ukraine did not follow through with that plan.) Now that Kaliningrad is on year-round UTC+2 (EET), this leaves only Belarus. It does not make sense to keep an invented grouping around to group one thing, so FET should go, and it has. But it equally doesn't make sense to group Belarus with Moscow just because Moscow changed its clocks. I may be wrong, 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. In any case, it hardly seems appropriate here.

[MSK] has the advantage of being recognized as an alias for UTC+3 by a reasonably large set of software already (which is unwise, but there it is).

I strongly believe that this is not enough reason to outweigh consideration of BYT and MINT. -- Tim Parenti

I see this approach as violently discriminatory. Although Belarus did formally declared independence in 1990 it took time to implement it and real independence was achieved only in December 1991 with disolvation of the Soviet Union. MSK used on the territory of current Belarus back then always meant "Moscow time" and there was no real concept or name such as "Minsk time" back then, so the "conservative" approach doesn't really apply here. -- Dzmitry Kazimirchyk On 4/2/15 2:07 AM, Paul Eggert 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.

On 4/2/15 12:13 PM, Lester Caine wrote:

Dzmitry ... That is exactly the reason that the rules for the TZ database deliberately try to avoid any political bias. I am often at odds with Paul over maintaining historic material, but any pre-1990 standards are maintained. We can't re-write history. But similarly it is not the job of the database to create it, so where there is no consensus, the historic base simply roles forward. The TZ database does not maintain a location mapping service, which is where the link between any ground location and a set of rules in TZ should be established, and it is that mapping service which would add any local descriptions and details. The TZ database simply provides a reliable set of rules that are accurate for the identifiers provided ... which are not locations.

Similarly I would then argue that changing Belarus time zone to MSK several months ago itself was rewriting history and had a political bias, since Belarus had its own time zone before that and didn't change any time keeping policies, so there was no immediate need to put the country into another time zone out from its own. I agree that creating a history is not the job of TZ database, but it is in fact creating history now (in one way or another) by making people believe that Belarus uses "Moscow time" (MSK), due to the well-known historical meaning of MSK which details were mentioned previously in this discussion and not only by me alone, and existence of a lot of software relying on TZ database out there to spread this information to the public. To quote TZ database's own maintenance guidelines [http://tools.ietf.org/html/rfc6557]: 3. Changes to existing entries SHALL reflect the consensus on the ground in the region covered by that entry. To be clear, the TZ Coordinator SHALL NOT set time zone policy for a region but use judgment and whatever available sources exist to assess what the average person on street would think the time actually is, or in case of historical corrections, was. Given that we all agreed that the commonly used name to denote time in Belarus is "Minsk time" and neither MSK nor "Moscow time" is used in the media and official sources for that purpose. I have a reason to believe that the recent change of time zone for Belarus to MSK doesn't adhere to the policies declared in this clause. I may be wrong, but if it is so hard to change time zone name for Belarus now, I don't understand why it was so easily changed to MSK months ago without considering MINT or BYT according to usual process as was suggested earlier. I thank everyone for their time and lots of useful information on the topic, but I am still not convinced that current situation with Belarus time zone is right and hope for some logical and unbiased resolution. -- Dzmitry Kazimirchyk

On 02/04/15 12:26, Dzmitry Kazimirchyk wrote:

On 4/2/15 12:13 PM, Lester Caine wrote:

...

The TZ database does not maintain a location mapping service, which is where the link between any ground location and a set of rules in TZ should be established, and it is that mapping service which would add any local descriptions and details. The TZ database simply provides a reliable set of rules that are accurate for the identifiers provided ... which are not locations.

Sorry for not including this in my previous message, but I don't think it is completely true. MSK unlike many other time zones is in fact locationaly tied to Moscow. Otherwise it wouldn't explain its rules changing in 2011 and 2014 following Russia's government decisions.

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. I can see a certain bias here: while Moscow region is conveniently preserving its own time zone abbreviation, Belarus is forced to jump here and there confusing software and everyone else, totally depending on Russia's government decisions and outside of its own control.

OK I've read the file again and the 2014 change is explained by ... http://eng.belta.by/all_news/society/Belarus-decides-against-adjusting-time-... Which specifically says in it's final paragraph 'The Moscow time will be used as the reference time to calculate the local time in these zones.' ... Is that not the published situation? MSK *IS* simply a rule set - Europe/Minsk is the time zone identifier which provides the link to the set of rules bing used. -- 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

On 02/04/15 13:17, Dzmitry Kazimirchyk wrote:

...

MSK*IS* simply a rule set - Europe/Minsk is the time zone identifier which provides the link to the set of rules bing used.

I understand, but it is there and is used to display time zone in software far more often than "Europe/Minsk".

As I understand it, the tz database merely documents common practice. So, for example, there was a longstanding debate about whether Australian timezones would be things like AEST or EST. The timezone identifiers resolutely stuck with EST instead of AEST until it was established that common (Australian) practise was to add the "A" at the beginning. (This was a very long saga, I hope I've got the gist of the story about right.) In the case of Minsk, do people in that locale most often say and write "MSK" in the way that the Australians write "AEST" and the British "GMT"? What documentary evidence is there for both MSK and an alternative? This is completely apolitical, it's purely geographical. It's what people who regard their timezone as Europe/Minsk habitually use for the timezone identifier. Does that make sense? jch

Date: Thu, 02 Apr 2015 17:38:52 +0300 From: Dzmitry Kazimirchyk <dkazimirchyk@gmail.com> Message-ID: <551D547C.2010200@gmail.com> | It makes an absolute sense. The problem here is that Belarus (as to my | knowledge as a local) doesn't have habitual time zone abbreviation | (other than maybe GMT+3/UTC+3), I believe that, and what's more, I suspect that it is true in most of the world - most of the abbreviations that are in the tz database were entirely invented here, and are more or less unknown in the areas of the zones to which they apply. The only reason they exist at all (aside from in those comparatively few countries with multiple zones and which use abbreviations to reference them, and western Europe (the EU area) which can almost be regarded as a country for these purposes) - for everyone else, the time is simply "the time" and if one ever wants to refer to some other time (other than GMT/UTC) is is mostly "the time in some place or other". Ideally, we'd simply make the things go away - but we can't, they're required because of the interface requirements (API definitions) of the functions that use the data - there must be something to return as the "timezone name" (because these interfaces were developed in the US, of course, and it's one of the countries that does use timezone abbreviations.) So, when there isn't one that is used, we just make one up - and hence, the controversies sometimes about what should be used where - anyone and everyone can argue about naming, because there's almost never one really correct answer (some answers might be better than others, given certain judgement criteria, but it is rare that one is right and all others are wrong.) But in another message you said ... | MSK unlike many other time zones is in fact which illustrates a complete misconception about what MSK is. It is not a timezone. It is a (meaningless) label that we attach to a timezone. Furthermore, should Russia decide to alter its times (again) and MSK (in Russia) represent a different offset from UTC, that would not mean that any other users of that same abbreviation need alter, regardless of what offset from UTC they happen to have (the things are NOT unambiguous, never have been, and never will be.) Unfortunately, sometimes here we have people who attempt to be "helpful" and give these strings some meaning (and to do that, change them when offsets alter), in an attempt to appease some broken software that's attempting to parse them - that's entirely counter-productive, and should be mercilessly squashed whenever it is encountered. Instead the broken software should be corrected. If (useful) time zone information needs to be attached to dates/times (which it often does) it should be in the UTC+3 or +0300 form, not "MSK" or anything like it. Anything using the abbreviations should be fixed - for your purposes, I'd have assumed that if you were going to tell people some name for the time, you'd want that to be in Cyrillic in any case, and not latin characters. Note that nothing I've said has any bearing on the question of what abbreviation should be used for the time in Belarus - I don't care, and nor should anyone else, that is, unless it were (along with all of the others, for all zones) be simply turned into XXX (literally "XXX") as an attempt to make it clear to people using it that they really shouldn't. kre

On 04/04/15 01:52, Guy Harris wrote:

...

- Europe/Minsk is the time zone identifier

...

which provides the link to the set of rules bing used. Sets of rules, plural - Europe/Minsk switched between "C-Eur", "Russia", and "-" i.e. "none", and is currently using "none" rather than "Russia" (as is Europe/Moscow).

That was my mistake ... I had not actually checked and had in mind that MSK was a Russian rule set ... rather than a single fixed offset. The problem with using any of the abbreviations as a timezone identifier is exactly the same problem as happens with the 'time offset' still incorrectly supplied via the browser. One has no idea if the client is in a DST zone or simply a fixed offset. The time zone identifier is the only thing that reliably identifies if DST is in use! -- 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

Hank W. <hankw1@austin.rr.com> wrote:

Furthermore, I would like very, very much to see ISO-3166-based replacements for at least some of the ambiguous abbreviations. In my opinion, saying that IST means UTC+1 AND UTC+2 AND UTC+5:30 is as ludicrous as if an inch were equal to 2.54 cm AND 3 cm AND 4 cm. For example,... Change Irish Summer Time from IST to IEST.

Remember that we are descriptive rather than prescriptive. I can’t speak for the Irish, but you would have a hard job trying to get GMT and BST (another ambiguous abbreviation signifying UTC+1) changed to GBT and GBST or GBDT.

Change China Standard Time from CST to CNST.

And, of course, change the other version of this ambiguous CST abbreviation to USST. Hmm, maybe this isn’t such a good idea after all. :-) Peter Ilieve

On 9 Apr 2015, at 20:59, Peter Ilieve <peter@aldie.co.uk> wrote:

Remember that we are descriptive rather than prescriptive. I can’t speak for the Irish, but you would have a hard job trying to get GMT and BST (another ambiguous abbreviation signifying UTC+1) changed to GBT and GBST or GBDT.

The British are emotionally attached to GMT :) We’ve been using GMT and BST for as long as I can remember, I’m pretty sure the abbreviations were in wide usage before computers were used as clocks. (I know that as a child we talked about "Winter Time" and "Summer Time” but I don’t recall ever seeing that written, but we’re talking about a long time ago.) jch

On 2015-04-13 15:45, Hank W. wrote:

I actually prefer the style used in North America, Europe and Africa of multiple countries using the same name for the same UTC offset rather than the style of South America and Asia of the same time offset having a different name in each country. It's neater and easier to handle, and it's easier to remember what the names stand for. For example, it's easier to remember that Central European Time is between Western European Time and Eastern European Time than it is to remember that Myanmar Time is UTC+6:30.

Out of curiosity, I recently decided to figure out which of the world's 41 different UTC offsets currently has the most names. The winner (or loser?) is UTC-3, which currently has 13 different names (Amazon Summer Time, Argentina Time, Atlantic Daylight Saving Time, Brasilia Time, Chile Summer Time, Falkland Islands Summer Time, French Guiana Time, Paraguay Summer Time, Pierre-et-Miquelon Standard Time, Rothera Time, Suriname Time, Uruguay Time and Western Greenland Time). I'm not suggesting that something be done to change this fact; I'm just sharing an interesting bit of trivia.

One thing I had intended to include in my previous message but forgot to is that I don't see anything wrong with ambiguous tz abbreviations that do not represent more than one UTC offset. PST is cool because Pacific Standard Time and Pitcairn Standard Time are both UTC-8, and AQTT is cool because Aqtobe Time and Aqtau Time are both UTC+5.

Apart from North America and EU time zones, which have common standard dates and times for DST start and end regardless of UTC offset, most other time zones have unique start and end date and time rules, or may not switch to DST in the tropics, e.g. UTC-3 rules include Arg, ArgAQ, Brazil, Canada, EU, Falk, Uruguay, so a common UTC offset or abbreviation says little about current and less about historical observances. -- Take care. Thanks, Brian Inglis