On 11/02/2016 08:50 AM, turchanov@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...).