[tz] Why did you rename Russian zone name abbreviations

[Paul Eggert]

On 11/02/2016 08:50 AM, turchanov at vl.ru wrote:
> ... having "date" command output "Wed Nov  2 09:54:58 +10 2016" make 
> it very difficult to understand where the system is.

That's fine, as the "date" command is supposed to be about *when*, not 
about *where*.

> 2. Since the inception of tzdata Olson stated rules for abbreviated 
> names clearly and unambiguously 
> (https://github.com/eggert/tz/blob/master/Theory):

That old guideline has been deprecated, as mentioned in the Theory file.

> 3. I have an impression that you (un-)intentionally confuse an 
> abbreviated name with a GMT offset.

No, the idea is that if there is no common English-language abbreviation 
for a time zone, tzdata uses a numeric abbreviation instead.

>
> if one needed a GMT offset it would have used %z-family flags.

The problem is not that software needs a GMT offset. It's that software 
unwisely requires a time zone abbreviation even when no such 
abbreviation exists in common English-language practice. Although we 
could simply leave the abbreviation empty in this case, it's more useful 
to fill it with a placeholder that conveys information to users of 
applications that unwisely output the abbreviation as-is.

> By changing the abbreviated zone name you in effect change the 
> original full zone name. Why didn't change Asia/Vladivostok to 
> Asia/+10 as well?!

That wouldn't work, as Vladivostok was at +11 before 2014, and at +09 
before 2011. Even in the US, where alphabetic time zone abbreviations 
are common, we wouldn't link America/Indiana/Petersburg to US/Eastern, 
because Petersburg observed Central Time before 2007.

>
> 5. You justify your decision to remove abbreviated names by declaring 
> them as an "invention".

Yes. I invented these abbreviations. I didn't use any formal procedure. 
The (now-deprecated) guideline about them in the Theory file was written 
after the fact, partly in an attempt to justify them.

When I invented those abbreviations, POSIX supported only 
alphabetic-only abbreviations. Also, I was naive about Russia: I thought 
that it kept time zones like the US does and that US-style alphabetic 
abbreviations therefore made sense for it. Nowadays, though, POSIX 
allows numeric abbreviations, and I know more about Russian practice.

 From an English-speaking point of view, abbreviations like VLAT are 
misleading because they imply that there is a time zone at a fixed 
offset from UTC called "VLAT", which is how abbreviations like "PST", 
"GMT", and "CET" work. However, abbreviations like "VLAT" do not 
correspond to fixed UTC offsets, and this is something that 
English-speakers are typically not expecting or accustomed to. So even 
if "VLAT" were widely used by Russian speakers, it would still be 
dubious as an abbreviation in English-language tzdata.

I agree that the current situation could be improved, and that there 
could be a better way to localize time zone abbreviations. I expect this 
is an effort that should be under the CLDR umbrella, as they're the 
localization gurus. It may be that we need a better API for getting at 
localized abbreviations. Certainly the tzcode strftime.c is incomplete 
here, as it doesn't even support Russian month names, much less 
genitive-case Russian dates (does CLDR handle that correctly? if not, it 
should...).