<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 1, 2016 at 12:12 PM, Paul Eggert <span dir="ltr"><<a href="mailto:eggert@cs.ucla.edu" target="_blank">eggert@cs.ucla.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 10/31/2016 01:39 PM, Alexander Belopolsky wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I wouldn't be surprised if similar practices exist in other non-English speaking countries<br>
</blockquote>
<br></span>
I'm afraid we don't have the resources to cover common practices in languages other than English,</blockquote><div><br></div><div>Well, clearly not making a change should take fewer resources than making it. I would think any change like this should be driven by input from the affected regions. Think how much havoc would it cause in the US if you would change EST/EDT to -05/-04. Many users would have no idea what these numbers mean. This is a general problem with UTC offsets: in the zones more than 1-2 hours away from the zero meridian the time at Greenwich is fairly irrelevant and people tend to refer to local times by name (as in the US), or by offset from the central zone (as in Russia). </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> even if these languages use Latin-letter abbreviations that may have been derived from English originally. This sort of thing is better addressed by CLDR <<a href="http://cldr.unicode.org/" rel="noreferrer" target="_blank">http://cldr.unicode.org/</a>>, which has a mandate to cover time zone abbreviations in non-English locales.<br></blockquote><div><br></div><div>I don't think CLDR can supply translation of +10 to VLAT without help from tzdb. In fact, I don't think CLDR even supports abbreviations - it looks like they only localize TZID's such as Asia/Vladivostok. Note that many systems don't bother translating the abbreviations even when the rest of the date display is localized.</div><div><br></div><div>For example on Linux, I get</div><div><br></div><div><div>$ TZ=Europe/Moscow LANG=ru_RU.UTF-8 date</div><div>Срд Ноя 2 20:50:12 MSK 2016</div></div><div><br></div><div>and on Mac OS X:</div><div><br></div><div><div>$ TZ=Europe/Moscow LANG=ru_RU date</div><div>среда, 2 ноября 2016 г. 20:48:10 (MSK)</div></div><div><br></div><div>In fact, I think POSIX made a mistake allowing %Z to be localized and most systems don't do that.</div><div><br></div><div>As a practical matter, while I appreciate all the theory behind the transition, it would be better to limit the changes to cases where "invented" abbreviations are reported to cause user confusion. (And what can be more confusing than EST? Being in the Western Hemisphere, it is not Eastern and being Winter time, it is not Summer!)</div></div></div></div>