On Thu, Jun 2, 2016, at 16:54, Paul Eggert wrote:
This is the sort of thing we're trying to move away from. Abbreviations like NOVT are our inventions and are rarely used outside the tzdata context; we really can't defend them.
Defend them from whom?
Another problem with abbreviations like NOVT is that their meanings change with time. For example, NOVT stands for +06 now, but it stands for +07 before October 2014, for +06 again before March 2011, etc. The ambiguity of "NOVT" is atypical for English-language time zone abbreviations, and this unexpected aspect of our invented abbreviations can easily confuse non-experts.
So fix them. No-one's saying they should continue *exactly* as they have been, just that whatever solution is arrived at should not be a bare number.
In contrast, abbreviations like +06 and +07 are unambiguous.
They're unclear as to what their units are or what they are to be added to. A field that has traditionally been a reasonably self-explanatory abbreviation is unlikely to exclusively appear in contexts where it's unambiguous that it is an offset in hours to be treated as a difference from UTC to identify the time zone.
So remove the feature entirely.
That's not a practical option, as time zone abbreviations are a standard part of ISO C, of POSIX,
To be clear, these fields are consistently and exclusively referred to as *names* in the relevant standards, and the restrictions that POSIX places on their contents (for example, no spaces) only apply, in a strict reading, to the "STDnDST..."-style TZ environment variable, and not to time zone names set in an implementation-defined manner from the other form of TZ environment variable. Windows uses full names, with this particular zone being called "N. Central Asia Standard Time".
and of many programming systems that use a tzcode-like interface, so we need to put *something* in there.
Sure. Put the numeric zone identifier in there. Preferably to the minute, if there's room, since that's what people expect. And put it there for *everyone*, and remove support for storing or loading a non-numeric abbreviation in the datafiles.
Numeric abbreviations are reasonable placeholders for zones lacking well-supported English-language time zone abbreviations.
Says who? This entire discussion was started by people who don't think that's reasonable. And I certainly don't think "The US and Europe get abbreviations and Russia does not" is reasonable.