[tz] Belarus is listed in MSK timezone

[Guy Harris]

On Apr 24, 2015, at 2:25 PM, Paul Ganssle <pganssle at 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).