[tz] Why did you rename Russian zone name abbreviations

Alexander Belopolsky alexander.belopolsky at gmail.com
Wed Nov 2 18:07:17 UTC 2016


On Tue, Nov 1, 2016 at 12:12 PM, Paul Eggert <eggert at cs.ucla.edu> wrote:

> On 10/31/2016 01:39 PM, Alexander Belopolsky wrote:
>
>> I wouldn't be surprised if similar practices exist in other non-English
>> speaking countries
>>
>
> I'm afraid we don't have the resources to cover common practices in
> languages other than English,


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).


> 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 <http://cldr.unicode.org/>, which has a mandate to cover time zone
> abbreviations in non-English locales.
>

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.

For example on Linux, I get

$ TZ=Europe/Moscow LANG=ru_RU.UTF-8 date
Срд Ноя  2 20:50:12 MSK 2016

and on Mac OS X:

$ TZ=Europe/Moscow LANG=ru_RU date
среда,  2 ноября 2016 г. 20:48:10 (MSK)

In fact, I think POSIX made a mistake allowing %Z to be localized and most
systems don't do that.

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!)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20161102/f817a1f6/attachment.html>


More information about the tz mailing list