<p dir="ltr">Certainly I didn't mean dropping it from the database. It's just that the MSK time zone abbreviation is new, so we can go back to what we were using before, or use the XXX convention mentioned in earlier emails.</p>
<p dir="ltr">My understanding is that FET was dropped because that was something Paul just made up, but given that MSK is not in common use and it's ambiguous, it's not really a good replacement.</p>
<p dir="ltr">I think using BYT makes the most sense because it follows an existing standardized nomenclature (which is probably the next best choice when the descriptive approach comes up empty) and because it's more descriptive of the actual time zone (it applies to all of Belarus uniformly, so no need to single out Minsk).</p>
<div class="gmail_quot<blockquote class=" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On Apr 24, 2015, at 2:25 PM, Paul Ganssle <<a href="mailto:pganssle@gmail.com">pganssle@gmail.com</a>> wrote:<br>
<br>
> 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.<br>
><br>
> I think that dropping out entirely could work,<br>
<br>
"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:<br>
<br>
<a href="http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/time.h.html" target="_blank">http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/time.h.html</a> (note "tzname")<br>
<br>
<a href="http://pubs.opengroup.org/onlinepubs/9699919799/functions/tzname.html" target="_blank">http://pubs.opengroup.org/onlinepubs/9699919799/functions/tzname.html</a><br>
<br>
(yes, it says<br>
<br>
The tzset() function shall set the external variable tzname as follows:<br>
<br>
tzname[0] = "std";<br>
tzname[1] = "dst";<br>
<br>
where std and dst are as described in XBD Environment Variables.<br>
<br>
and "XBD Environment Variables" says<br>
<br>
TZ<br>
<br>
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):<br>
<br>
:characters<br>
or:<br>
<br>
std offset dst offset, rule<br>
<br>
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.<br>
<br>
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).<br>
</div>