[tz] Why did you rename Russian zone name abbreviations
eggert at cs.ucla.edu
Wed Nov 2 20:17:13 UTC 2016
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
> 2. Since the inception of tzdata Olson stated rules for abbreviated
> names clearly and unambiguously
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
More information about the tz