random832 at fastmail.com
Thu Jun 2 22:05:51 UTC 2016
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
> 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.
> 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.
More information about the tz