[tz] Asia/Tomsk

[Random832]

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.