Yes , but when you say "identifier", I think "Europe/Minsk", not "MSK". Do you consider both to be identifying a rule set? ________________________________ From: Lester Caine<mailto:lester@lsces.co.uk> Sent: 4/3/2015 1:15 AM To: tz@iana.org<mailto:tz@iana.org> Subject: Re: [tz] Belarus is listed in MSK timezone On 03/04/15 08:22, Matt Johnson wrote:
How can we even hope to achieve time zone abbreviations that follow what people use on the ground if some places don't use abbreviations at all?
While on one hand the bulk of the current rules are well established, some edge cases simply need a unique identifier for the internal rule set being referred to. I'll repeat what I keep saying ... the local 'conversion' of the descriptions is not something that the TZ database has any control over, and in some cases the internal identifiers are simply that ... internal ... only requiring that they uniquely identify a particular rule set. -- 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 03/04/15 20:34, Matt Johnson wrote:
Yes , but when you say "identifier", I think "Europe/Minsk", not "MSK". Do you consider both to be identifying a rule set?
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. 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. On the tzdist protocol every single identifier will have it's own duplicate set of information, so the rule set base is not identified and one can use any names one likes for what is essentially the same set of data. If there is a change to one of the generic rule sets every data set using it has to be pushed as an update, rather than just publishing the one change of rules. -- 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
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
Dzmitry Kazimirchyk wrote:
I would agree with one rule set - one name policy if it was strictly observed by the TZ database.
That would require inventing names for time zones, and we try to avoid doing that when possible. The goal is to describe timekeeping practice, not to prescribe it. In hindsight the tz database could have supported having no abbreviation for zones where abbreviations are not commonly used, and this would have avoided some similar problems elsewhere where we use "zzz" for time zone abbreviations in some cases; but this would have entailed some confusion and/or compatibility hassles at the time the database was being introduced and it's impractical to revisit this design decision now. 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.
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 Apr 3, 2015, at 4:20 PM, Dzmitry Kazimirchyk <dkazimirchyk@gmail.com> wrote:
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.
What about the problems caused by their usage, such as their ambiguity? I'd *REALLY* like to see them deprecated. Note that the _tzname[] array in Windows contains long names, not abbreviations, so there's a fair bit of software out there that doesn't use them to display formatted dates on Windows. (Wireshark on Windows, for example, uses the _tzname[] array, so Wireshark on Windows doesn't say "PST", it says "Pacific Standard Time". It might even say something different in different locales, i.e. it might show it in the locale's language rather than in English.) But if you don't want them downplayed, please suggest an abbreviation to use for Minsk time.
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
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.
+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.
Even so that would likely be easier to disambiguate from context than Minsk/Moscow. On Apr 3, 2015 9:31 PM, "Arthur David Olson" <arthurdavidolson@gmail.com> wrote:
+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
Tim Parenti wrote:
why didn't we refer to Minsk Time as MSK instead of FET in 2011–2014?
Because we thought that there would be a new time zone between Eastern European Time and Moscow time, one that could use a name. If that had happened stably, we could have extended the European naming tradition (WET, CET, MET, EET) one time zone to the east. It turns out that we were wrong; sorry.
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. 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.
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
On 04/04/2015 03:28 AM, Paul Eggert 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. 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.
Are you considering the "situation on the ground" rule political? 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. Here are several completely apolitical reasons to back my line of thought: 1. I think there is a wide agreement that "Minsk time" and "Moscow time" are not the same terms and both are used separately to denote time in their respective countries (or regions); 2. According to (1) and due to the lack of historical or common abbreviation for "Minsk time" community should have picked the abbreviation as per standard procedure which would have suggested MINT or BYT (and absolutely not MSK) as it was mentioned before; 3. I've brought up an example of Kazakhstan which while being in the same situation as Belarus was, have preserved its own time zone abbreviations and haven't had it replaced. I think the argument that Europe/Minsk was using MSK several decades ago is somewhat far-fetched as it was really using "Moscow time" and not the "Minsk time". And I'm really hoping that its usage here is truly not biased and is not just to cement previously made questionable decision which wouldn't have been taken in a first place if the community was aware of all the facts involved. -- Dzmitry Kazimirchyk
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 04/05/2015 12:32 AM, Paul Eggert wrote:
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.
Not quite, MMT actually looks like natural abbreviation for both terms (produced by taking first letter of each word) unlike MSK which following this logic doesn't really look natural for neither of "Minsk time", "Moscow time", but is directly transliterated from traditional Russian abbreviation for "Moscow time" and is historically associated with it. To go further, MSK doesn't seem to be analogous to PST and AST examples mentioned earlier since it isn't natural abbreviation like they are (but rather an abbreviation used "on the ground" to denote "Moscow time" and adopted by TZ database for the exact same purpose), hence the logic behind using it for "Minsk time" on this basis doesn't seem to be entirely applicable. Natural abbreviation for both terms would be something like MST which would be neutral and entirely acceptable to denote both of them, but MSK in my opinion is just not something falling into that category. Furthermore, TZ database doesn't seem to store full time zone names associated with abbreviations it uses. So I guess the consumers of TZ database data are making these associations themselves using some other sources available to them. Which with current MSK situation is already resulting in certain misconceptions like for example here: http://localtimes.info/Europe/Belarus/Minsk/ -- Dzmitry Kazimirchyk
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.
Seeing that the discussion on the topic had died and hasn't come to any obvious conclusion as I see it (sorry if I haven't noticed something), and "Minsk time" is still being denoted as MSK in the recent tz database release, I would like to ask if it is the final decision on the matter or is there still room for further discussion. If, regretfully, it is the final decision I would like for the last time to kindly ask about the main reasoning behind it given all the facts mentioned in this thread, and if possible explanation of how the recent change to MSK can be justified considering all these facts. I apologize for making you reiterate through all this all over again, but this issue is really concerning and the damage, i.e. misinformation (e.g. http://localtimes.info/Europe/Belarus/Minsk/), is being done. Thank you. -- Dzmitry Kazimirchyk
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.
On 23/04/15 11:42, Paul Eggert wrote:
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.
It is also perhaps surprising how much more historic data is being uncovered over time to fill in other gaps. This needs local input, so just as today we rely on notifications such as for the change in Egypt time, if there is documentary evidence for any correction to a name or abbreviation it needs pointing out just as much? -- 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
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 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.
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
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, or alternately it seemed there was a strong case for BYT or MINT. My preference between those two would be BYT if there has to be a three letter abbreviation. On Apr 24, 2015 3:29 PM, "Dzmitry Kazimirchyk" <dkazimirchyk@gmail.com> wrote:
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).
Certainly I didn't mean dropping it from the database. It's just that the MSK time zone abbreviation is new, so we can go back to what we were using before, or use the XXX convention mentioned in earlier emails. My understanding is that FET was dropped because that was something Paul just made up, but given that MSK is not in common use and it's ambiguous, it's not really a good replacement. I think using BYT makes the most sense because it follows an existing standardized nomenclature (which is probably the next best choice when the descriptive approach comes up empty) and because it's more descriptive of the actual time zone (it applies to all of Belarus uniformly, so no need to single out Minsk). 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 23/04/15 19:34, Dzmitry Kazimirchyk wrote:
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?
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. -- 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 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
On Apr 23, 2015, at 5:08 PM, Garrett Wollman <wollman@csail.mit.edu> wrote:
<<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.
No, I think what he’s doing is refusing to make any changes whose reasoning is political, which makes sense. The problem is that it would open the floodgates to all sort of stuff we don’t need, like debates about what country certain towns are in, or what countries exist, and so forth. paul
Dzmitry Kazimirchyk wrote:
I can see both Pacific Standard Time and Pitcairn Standard Time in the list here:
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.
On 04/04/2015 02:46 AM, Paul Eggert wrote:
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.
timeanddate.com was just the first link I found and I used it only to show the generic issue. Even if timeanddate.com keeps itself in sync with TZ database and will eventually update, most of the resources are not updating very often or not syncing to TZ database at all, moreover public knowledge and association of MSK with "Moscow time" will not change in years to come or even change at all. I still don't think that it is right to use MSK for "Minsk time", as I've said there is a complete lack of awareness or any association of MSK with "Minsk time" and I don't think that TZ database alone has ability to change that.
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 think that technical hassle is not the biggest issue in current situation. -- Dzmitry Kazimirchyk
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
On Apr 3, 2015, at 2:28 PM, Dzmitry Kazimirchyk <dkazimirchyk@gmail.com> wrote:
The key concept here is that "the rule itself doesn't change". I don't believe MSK can be considered a rule set
Does *anybody* here believe it can? Not as far as I know. The "europe" file has Zone Europe/Minsk 1:50:16 - LMT 1880 1:50 - MMT 1924 May 2 # Minsk Mean Time 2:00 - EET 1930 Jun 21 3:00 - MSK 1941 Jun 28 1:00 C-Eur CE%sT 1944 Jul 3 3:00 Russia MSK/MSD 1990 3:00 - MSK 1991 Mar 31 2:00s 2:00 1:00 EEST 1991 Sep 29 2:00s 2:00 - EET 1992 Mar 29 0:00s 2:00 1:00 EEST 1992 Sep 27 0:00s 2:00 Russia EE%sT 2011 Mar 27 2:00s 3:00 - FET 2014 Oct 26 1:00s 3:00 - MSK so the zone name is named "Europe/Minsk". That zone uses various rule sets; it's currently not using *any* rule set, although it's used the "C-Eur" and "Russia" rule sets in the past. (The zic man page speaks of "set[s] of rules" rather than "rule set[s]", but those are just different names for the same thing.) You're talking about the *abbreviation* used when formatting times, not about the name for a rule set. "MSK" - and "FET", and so on - are abbreviations used when formatting times, not names for rule sets; it would be as big a mistake to refer to "MSK" as the name of a rule set as it would be to refer to "EST" or "EDT" or "PST" or "PDT" or "CET" as the names of rule sets. And, in fact, there's no "CET" rule set; there's a "C-Eur" rule set, and there are some zones that use the "C-Eur" rule set but *don't* use CET or CEDT or anything such as that as the abbreviation (Europe/Sofia and Europe/Bucharest used EE%sT with "C-Eur", and Europe/Luxembourg used WE%sT with "C-Eur", at one point, for example). Rule sets and abbreviations are separate things. So the question here is what should the abbreviation be. I don't know where the notion of designating times as, say, "5PM EST", for 17:00 in the Eastern time zone when daylight savings time/summer time is not in effect, originated; in particular, I don't know whether it started in the English-speaking world and, if it did, what countries and cultures have adopted it. It may be that Belarus never adopted it; Paul's mail shows some Belarusian sites showing times as, for example, "19h00 Minsk time". The UN*X tradition, somewhat standardized in the Single UNIX Specification description of the TZ environment variable, has 3-or-more-character strings not containing spaces, so "Minsk time" wouldn't work for that. That's why abbreviations such as "MSK" were invented. It Might Be Nice if there were standard UN*X APIs to get more descriptive zone names. On Windows, _tzname[] contains strings such as "Pacific Daylight Time", so it could presumably say "Minsk time" in Belarus (although it'd probably say it in Belarusian by default). The CLDR appears to include descriptive zone names. However, we probably still need to supply an abbreviation. If abbreviations (rather than phrases such as "Minsk time") are used in Belarus, what abbreviation is used? Our database isn't internationalized - that's the CLDR's job - so that would be "used in English-language text in Belarus". If abbreviations *aren't* used in Belarus, are they used in any other countries when talking about Minsk time? If so, what abbreviation is used in English-language text? If they're not used *anywhere*, we have to pick one; what one would you recommend?
participants (11)
-
Arthur David Olson -
Dzmitry Kazimirchyk -
Garrett Wollman -
Guy Harris -
Lester Caine -
Matt Johnson -
Paul Eggert -
Paul Ganssle -
Paul_Koning@dell.com -
random832@fastmail.us -
Tim Parenti