On Apr 24, 2015, at 2:25 PM, Paul Ganssle <pganssle@gmail.com> wrote:
I have to say, I was originally very skeptical about this proposal because it seems like it would be political, but if MSK really isn't used locally, it probably shouldn't be in the DB regardless of the political implications, particularly if a identical abbreviation is used elsewhere.
I think that dropping out entirely could work,
"Dropping out" as in "remove Minsk time from the database", which wouldn't work very well for users in Belarus, or "dropping out" as in "don't supply any abbreviation", which wouldn't work very well for those UN*X mechanisms that supply time zone abbreviations: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/time.h.html (note "tzname") http://pubs.opengroup.org/onlinepubs/9699919799/functions/tzname.html (yes, it says The tzset() function shall set the external variable tzname as follows: tzname[0] = "std"; tzname[1] = "dst"; where std and dst are as described in XBD Environment Variables. and "XBD Environment Variables" says TZ This variable shall represent timezone information. The contents of the environment variable named TZ shall be used by the ctime(), ctime_r(), localtime(), localtime_r(), strftime(), mktime(), functions, and by various utilities, to override the default timezone. The value of TZ has one of the two forms (spaces inserted for clarity): :characters or: std offset dst offset, rule If TZ is of the first format (that is, if the first character is a <colon>), the characters following the <colon> are handled in an implementation-defined manner. with the latter being an escape hatch put in for the benefit of the Olson database and code, as it was called back then, so one *could* try arguing that POSIX would not impose any constraints on what we do with tzname[] with a tzdb zone setting, but, in practice, that argument will probably fall on deaf ears).